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ABSTRACT 


The  REpresentation  and  MAintenance  of  Process  knowIedge(REMAP)  model  supports  the 
various  stakeholders  involved  in  software  design  during  development  and  maintenance  by  capturing 
the  rationale  behind  design  decisions.  This  process  knowledge  is  invaluable  with  changing 
requirements  and  assumptions.  In  the  context  of  formal  software  development,  process  knowledge 
about  the  development  of  formal  specifications  from  informal  requirements  will  facilitate  the 
understanding  and  maintenance  of  such  specifications.  We  have  implemented  the  REMAP  model  in 
the  United  States  Air  Force  Rome  Laboratory’s  KBSA  Concept  Demonstration  system  (a  forma! 
software  development  environment)  to  capture  this  process  knowledge.  We  provide  a  graphical 
browser  to  facilitate  the  instantiation,  browsing  and  modification  of  REMAP  model  primitives  and 
a  mechanism  to  reason  with  the  knowledge  in  the  Concept  Demonstration  system. 
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I. 


INTRODUCTION 


A.  GENERAL 

Software  expenditures  have  expanded  exponentially  over  the 
previous  decade.  Software  maintenance  has  accounted  for  the 
majority  of  these  costs.  There  is  growing  recognition  that, 
an  important  way  of  curtailing  the  high  cost  of  system 
maintenance  is  to  capture  the  rationale  used  to  create 
requirements  and  designs,  and  maintain  this  information 
throughout  the  software  life-cycle[Ref .  1].  This 

thesis  implements  a  model  for  representing  design  rationale  in 
the  context  of  software  development  based  on  formal 
specifications. 

B.  BACKGROUND 

The  Department  of  Defense  (DoD)  spends  nearly  $10  billion 
per  year  on  software.  Numerous  Studies  have  estimated  that 
maintenance  costs  can  be  70  to  80  percent  of  the  total  life- 
cycle  costs.  With  declining  defense  dollars,  it  is  important 
to  develop  systems  that  are  easier  to  maintain  and  implemented 
economically. [Ref .  2] 

Recent  research  has  recognized  that  capturing  and  using 
rationale  for  the  requirements  and  designs  throughout  the 


1 


development  life-cycle  will  help  alleviate  the  high  cost  of 
maintenance . [Ref .  3]  Requirements  and  design 
rationale  can  be  used  in  the  later  stages  of  the  system  life- 
cycle  to  effect  changer  ^ud  to  facilitate  reuse  of  components, 
"^is  data  can  also  be  used  in  the  DoD  environment  as  a 
component  of  lequirements  traceability.  Design  rationale  is 
often  the  outcome  of  deliberations  by  members  of  the  design 
team.  The  focus  of  capturing  design  deliberations  is  to 
associate  the  decision  making  process  to  a  particular 
specification  or  design  component.  This  information  will 
create  a  historical  database  where  the  user  can  identify  how 
the  requirements  have  evolved  and  provide  the  knowledge 
necessary  to  identify  repercussions  of  changing  requirements 
on  the  design. 

Previous  research  has  produced  several  models  for 
capturing  design  rationale  knowledge.  A  model,  called 
Representation  and  Maintenance  of  Process  knowledge  (REMAP) , 
"recognizes  the  importance  of  capturing  process  knowledge  to 
reason  about  the  consequences  of  changing  conditions  and 
requirements  in  system  design  and  maintenance." 
[Ref.  4]  This  model  includes  IBIS,  a  model  that  has 
been  widely  used  for  representing  deliberations.  Our  research 
aims  at  developing  an  implementation  of  REMAP  in  an  effort  to 
capture  valuable  design  rationale  knowledge. 
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within  DoD,  the  Air  Force's  Rome  Laboratory  (RL)  is 
investigating  the  creation  of  a  Knowledge-Based  Software 
Assistant  (KBSA)  through  research  conducted  in  both  academia 
and  the  corporate  world.  On  behalf  of  RL,  Andersen  Consulting 
has  synthesized  the  results  of  over  a  decade  of  research  in 
this  area,  into  a  product  called  KBSA  Concept  Demonstration 
system.  This  tool  uses  formal  specifications  to  create 
software  products.  A  major  concern  with  the  use  of  formal 
specification  based  software  development  is  the  difficulty 
users  face  in  arriving  at  specifications.  Further,  with  this 
paradigm,  the  process  of  maintenance  is  done  at  the  level  of 
specifications.  Therefore,  it  is  essential  to  capture  the 
essence  of  the  process  of  arriving  at  formal  specifications, 
so  that  they  can  be  easily  understood  and  maintained.  This 
process  of  defining  formal  specifications  from  the  initial  set 
of  informal  requirements  can  be  thought  of  as  a  deliberation. 
In  this  thesis,  the  REMAP  model  will  be  used  to  represent  the 
deliberations . 

C.  THESIS  OBJECTIVE 

This  thesis  examines  and  implements  an  extension  of  the 
DoD-sponsored,  KBSA  Concept  Demonstration  system  using  the 
REMAP  deliberations  capture  model. 
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D.  RESEARCH  QUESTIONS 


What  is  the  importance  of  capturing  requirements  design 
deliberations,  in  the  context  of  software  development  based  on 
formal  specifications? 

How  is  the  REMAP  model  implemented  into  the  Concept 
Demonstration  system  for  Knowledge-Based  Software  Engineering*’ 


E.  SCOPE 

The  scope  of  this  thesis  is  limited  to  a  brief  overview  of 
design  rationale  capture  during  requirements  engineering,  and 
software  development  based  on  formal  specifications.  A  more 
detailed  description  of  two  specific  examples,  REMAP  and 
Concept  Demo,  will  be  provided.  This  thesis  will  concentrate 
on  the  process  of  designing  and  implementing  the  REMAP  model 
by  extending  Concept  Demo.  A  graphical  browser  instantiates 
REMAP  nodes  and  links  consistent  with  the  Concept 
Demonstration  format  to  capture  the  design  rationale  into  the 
knowledge-base . 


4 


F.  DEFINITIONS  AND  ABBREVIATIONS 

KBSA  Knowledge-Based  Software  Assistant 

REMAP  Representation  and  Maintenance  of  Process 

knowledge 

IBIS  Issue  Based  Information  Systems  method 

Concept  Demo  KBSA  Concept  Demonstration  System 
REMAP/CD  Thesis  implementation  of  a  Concept  Demo 

extension  including  REMAP 

6.  ORGANIZATION  OF  STUDY 

Beyond  this  introduction  the  thesis  consists  of  four  major 
chapters.  Chapter  II  contains  an  introduction  to  the  KBSA 
Concept  Demonstration  system.  A  brief  history  and  current 
status  will  explain  what  KBSA  is  intended  to  accomplish  and 
where  this  software  development  paradigm  based  on  formal 
specifications  fits  in  the  Department  of  Defense  (DoD) 
information  technology  structure.  Chapter  III  discusses 
design  rationale  deliberation  capture  and  examines  in  detail 
the  various  elements  of  the  REMAP  model  used  to  facilitate 
capture  in  this  project.  Chapter  IV  focuses  on  the  specific 
steps  necessary  to  develop,  integrate,  and  use  the  REMAP 
extension  implemented  in  Concept  Demo.  Finally,  Chapter  V 
details  conclusions  and  recommendations. 
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II.  KBSA  CONCEPT  DEMONSTRATION 


A.  GENERAL 

In  1982,  U.S.  Air  Force's  Rome  Air  Development  Center 
(RADC) ,  currently  designated  Rome  Laboratory,  began 
envisioning  a  new  approach  to  solving  "the  software  problem". 
In  1983,  RADC  published  "Report  on  a  Knowledge-Based  Software 
Assistant"  [Ref.  5]  delineating  possible  artificial 
intelligence  (AI)  uses  in  integrating  a  systems  approach  to 
the  complete  software  life-cycle.  The  Knowledge-Based  Software 
Assistant  (KBSA)  offered  a  potential  solution  to  issues 
relating  to  software  productivity,  quality  and  life  cycle 
costs.  [Ref.  6] 

The  Knowledge-Based  Software  Assistant  is  a  formally- 
structured  knowledge-based,  software  design,  development,  and 
maintenance  tool  that  encompasses  the  entire  software  life- 
cycle.  This  new  paradigm  combines  formalization  with 
automation  to  achieve  four  distinguishing  features.  These 
are: 

incremental,  formal,  and  executable  specifications; 
formal  implementation  where  verification  and  validation 
arise  from  the  implementation  development  process; 

enforced  project  management  policy  maintaining  consistent 
relationships  between  various  software  objects;  and, 

high  level  system  development  and  maintenance  accomplished 
at  the  requirements  and  specification  levels. 

Implementation  of  these  novel  concepts  and  features  would 
occur  in  an  evolutionary,  three-phase  contractual  approach. 
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Phase  I  involved  dividing  the  concept  into  modules  or 
"facets”.  Individual  organizations  concentrated  on  specific 
facets  (e.g.,  Project  Management  Assistant,  Requirements 
Assistant)  while  maintaining  a  consistent  formalism  for  later 
integration. 

Phase  II  began  combination  of  some  appropriate  facets 
(e.g.,  Requirements/Specification  Assistant)  and  the  creation 
of  a  demonstration  system  (Concept  Demo)  to  assist  in 
implementation  and  acceptance  of  this  new  paradigm. 
[Ref.  7] 

Phase  III  will  involve  the  Advanced  Development  Model 
(ADM)  which  further  integrates  the  preceding  facets  to  provide 
a  more  usable  product.  [Ref.  8] 

This  chapter  will  provide  a  history  of  Phase  I  and  II. 
Knowledge-Based  System  Engineering  (KBSE)  using  the  REFINE 
programming  language  will  be  discussed  in  the  context  of  KBSA, 
and  finally,  an  expanded  discussion  of  Concept  Demo  will 
provide  a  system  overview  and  the  rationale  for  choosing  it  to 
implement  REMAP. 

B.  HISTORY  OF  KBSA  DEVELOPMENT 

The  following  is  a  brief  history  of  KBSA  development, 
presented  by  research  organization  in  roughly  the  order  in 
which  each  began  work  on  a  facet. 

1 .  KESTREL  INSTITUTE 

The  Kestrel  Institute  began  designing  and  constructing 
a  Project  Management  Assistant  (PMA)  prototype  in  1984. 
[Ref.  9] [Ref.  10]  Kestrel  incorporated  three 
types  of  capabilities  into  the  design.  (1)  Project 
definition,  (2)  project  monitoring  and  (3)  an  effective  user 


7 


interface  allow  PHA  to  provide  knowledge-based  support  through 
project  communication,  coordination,  and  task  management. 
[Ref.  11]  PMA  is  a  step  beyond  traditional  project 
management  tools.  In  addition  to  typical  utilities  found  in 
these  tools,  (e.g..  Pert  and  Gantt  Charts,  test  cases  and 
results,  milestones)  PMA  understands  implicit  relationships 
between  products,  and,  using  powerful  temporal  relationships, 
provides  a  mechanism  for  formally  expressing  and  enforcing 
project  policies.  The  initial  PMA  was  completed  in  1986,  an 
expanded  version  was  completed  in  1990.  [Ref.  12] 

Development  of  Performance  Assistant  (PA)  began  in 
1985.  PA  was  designed  to  assist  with  performance  optimization 
at  many  levels  in  the  software  development  cycle.  Kestrel 
Institute  concentrated  on  two  primary  areas  to  permit  high- 
level  programming  in  a  wide  variety  of  languages  to  produce 
efficient  code  within  the  bounds  of  the  KBSA  paradigm.  (1) 
Control  optimization  established  efficient  and  formal 
transformations  effecting  specification  to  code  conversion, 
and  (2)  data  optimization,  including  data  structure  selection, 
created  efficient  object  types  for  copying,  storage, 
retrieval,  etc.  [Ref.  13] [Ref.  14] 

The  Development  Assistant  (DA)  effort  began  in  1988. 
Sharing  and  expanding  many  capabilities  from  Performance 
Assistant,  the  DA  uses  PA's  efficient  optimization  techniques 
and  integrated  these  more  closely  into  the  KBSA  paradigm. 
This  key  facet  supports  the  construction  of  the  application 
domain  to  include  system  specifications.  Formal  specification 
transformations  provide  detailed  code.  High-level  decisions 
can  be  quickly  and  systematically  implemented  and  considered. 
[Ref.  15] 
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2 .  SANDERS  ASSOCIATES 

In  1985,  Sanders  Associates  began  work  on  the 
Knowledge-Based  Requirements  Assistant  (KBRA)  .  KBRA  provided 
the  important  functionality  of  accepting  informal  requirement 
definitions  with  incompleteness  and  inconsistency,  and 
building  and  maintaining  these  in  a  consistent  internal 
representation.  This  representation  could  be  manipulated  to 
provide  multiple  views,  formats  and  tools  for  an  iterative 
requirement  definition  phase.  [Ref.  16] 

3 .  HONEYWELL  SYSTEMS 

In  1986,  Honeywell  Systems  and  Research  Center  began 
work  on  KBSA  Framework.  Framework  took  a  full  scale  approach 
with  two  goals  in  mind,  (1)  integrating  a  KBSA  demonstration 
and  (2)  building  upon  the  demonstration  to  logically  and 
consistently  interconnect  the  various  KBSA  facets.  Efforts  in 
this  area  include  (1)  determining  minimum  functionality  to 
combine  all  facets,  (2)  developing  a  common  interface  for 
facets  to  mesh,  and  for  users  to  interact  with  the  system,  (3) 
support  for  programming-in-the-large  concepts,  and  (4) 
providing  functionality  for  a  distributed  environment.  The 
Honeywell  effort  provided  a  common  language,  the  Common  LISP 
Object  System  (CLOS) ,  The  KBSA  User  Interface 
Environment (KUIE) , and  a  preliminary  Configuration  and  Change 
Management (CCM)  model  for  KBSA. 

[Ref.  17] [Ref.  18] 

4 .  UNIVERSITY  OF  SOUTHERN  CALIFORNIA  INFORMATION  SCIENCES 

INSTITUTE (ISI) 

ISI  began  its  effort  to  develop  a  KBSA  Specification 
Assistant  in  1985.  ISI's  goal  was  to  facilitate  the 
development  of  formal  executable  specifications.  They  use  two 
methods,  (1)  a  top  down  method  in  which  the  system 
specification  is  incrementally  elaborated,  and  (2)  an 
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evolutionary  method  that  iteratively  changes  or  transforms  the 
specification  as  development  of  the  system  continues.  In 
1988,  ISI  and  Lockheed  Sanders  began  merging  the  Sanders 
Knowledge-Based  Requirements  Assistant  and  the  ISI 
Specification  Assistant  into  a  system  called  ARIES. 
[Ref.  19] 

5 .  SOFTWARE  OPTIONS 

Transaction  Graphs  were  developed,  in  1988  by  Software 
Options,  to  formally  define  a  graphical  syntax  that  could  be 
used  to  specify  and  enforce  the  coordination  of  the  many  KBSA 
activities  that  would  be  used  consistently  throughout  the 
system.  [Ref.  20] 

6 .  ANDERSEN  CONSULTING 

The  creation  of  a  complete  demonstration  system 
involving  concepts  of  KBSA  commenced  in  1988  and  was  termed 
KBSA  Concept  Demonstration  (Concept  Demo) .  The  Concept  Demo 
is  a  system  that  combines  the  technologies  previously 
described.  This  Refine-based  demonstration  system  will  be 
described  in  detail  in  the  following  section. 

The  figure  on  the  following  page  provides  the  KBSA 
Research  Program  Overview. 
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Original  Plan  for  KBSA  Architecture* 


Figure  i 

C.  KK0WLGD6E-BASED  SOFTWARE  ENGINEERING  USING  REFINE' 

Knowledge-based  software  engineering  is  a  software 
development  approach  that  analyzes  program  characteristics  and 
application  domain  so  that  information  gained  can  be 
formalized  and  added  to  a  knowledge-based  compiler,  thus 
permitting  knowledge  to  be  automated.  This  approach  is 
valuable  because  it  fosters  automatic  reuse  of  knowledge. 
[Ref.  21] 

One  of  the  first  knowledge-based  commercial  software 
development  environments,  and  the  first  to  provide  powerful 
transformational  programming  features,  is  Reasoning  Systems' 
REFINE™.  REFINE™ 's  principal  features  are  (1)  the  REFINE™ 
Specification  Language,  (2)  the  REFINE™  Specification 


'  REFINE  is  a  registered  trademark  and  codemark  of 
Reasoning  Systems,  Inc.,  Palo  Alto,  CA. 
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Compiler,  and  (3)  the  REFINE™  knowledge  base  management 
system.  [Ref.  22]  These  features  combined  with 
REFINE™ 's  extendibility  and  flexibility  provided  an  ideally 
compatible  environment  for  incorporation  of  the  KBSA  paradigm 
into  a  concept  demonstration  system. 


D.  CONCEPT  DEMONSTRATION 

Andersen  Consulting  created  Concept  Demo  with  an  important 
goal  of  communicating  the  KBSA  approach  to  software 
development.  Concept  Demo  displayed  the  full  range  of  KBSA 
functionality,  from  capturing  informal  requirements  to 
generation  of  efficient  code,  with  emphasis  on  those  functions 
that  differentiate  KBSA  from  conventional  CASE  tools.  Using 
a  REFINE™  software  development  environment,  Andersen 
Consulting  integrated  facets  from  previous  KBSA  projects  where 
feasible,  and  re-implemented  equivalent  functionality  when 
necessary  to  provide  consistency  throughout  the  demonstration 
system.  [Ref.  23]  KBSA  Concept  Demo  provided  an 
extendible,  formalized  development  system  capable  of 
generating  and  maintaining  efficient,  low-level  code  createu 
through  a  transformation  process  initiated  at  the  requirements 
definition  phase. 
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'•^I.  REMAP 

A.  GENERAL 

Chapter  II  described  the  KBSA  Concept  Demonstration 
System's  functionality  during  the  system  life-cycle  from 
informal  design  requirements  capture  to  generation  and 
maintenance  of  efficient  code.  Research  has  shown  the  value 
of  capturing  not  only  design  requirements,  but  also,  the 
design  history,  intermediate  artifacts,  and  the  deliberation 
process  relating  to  the  development  of  design 
solution. [Ref .  24]  Design  information  reuse  for 

similar  systems,  and  system  maintenance  are  facilitated  by 
capture  and  use  of  this  process  knowledge. 

The  Representation  and  Maintenance  of  Process 
knowledge (REMAP)  model  was  used,  in  the  context  of  Concept 
Demo,  for  providing  this  functionality.  REMAP  was  developed 
using  an  empirical  study  on  problem-solving  behavior  of 
individuals  and  groups  engaged  in  systems  development.  The 
model  represents  deliberations  that  could  occur  in  any  systems 
development  entity.  The  REMAP  specifically  investigates  the 
process  knowledge  attributed  to  the  objects  created  during  the 
requirements  engineering  process. [Ref.  25]  The 

REMAP  model  is  based  on  and  expands  the  Issue  Based 
Information  System  (IBIS)  method  as  shown  in  Figure  2. 

B.  IBIS  MODEL 

The  IBIS  is  a  method  to  represent  argumentation 
processes. [Ref .  26] 

The  IBIS  model  is  comprised  of  three  primitives  or  nodes. 
These  are  ISSUE,  POSITION  and  ARGUMENT.  These  primitives  are 
connected  by  relationship  links  as  shown  in  Figure  2. 
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The  IBIS  model  is  contained  within  the  REMAP  model  and 
isolated  for  convenience  by  the  dotted-line  box. 

Useful  information  concerning  deliberations  can 
effectively  be  represented  using  the  IBIS  method.  An  ISSUE 
can  generalize  or  specialize  another  ISSUE,  and  the 
relationships  between  nodes  (e.g.,  POSITIONS  and  ARGUMENTS) 
can  be  preserved  in  both  a  positive  (supports)  and 
negative (objects  to)  sense.  The  REMAP  model  extends  the  IBIS 
model  to  include  additional  representations,  tailoring  it  to 
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the  representation  of  design  rationale  knowledge  in  systems 
development. 

C.  REMAP  MODEL 

The  REMAP  model  incorporates  primitives  to  model  the 
iterative  nature  of  real-world  requirements  engineering.  As 
shown  in  Figure  2,  the  additional  primitives  of  REMAP  are: 
REQUIREMENT,  DECISION,  ASSUMPTION,  CONSTRAINT,  and  DESIGN 
OBJECT.  The  IBIS  model  lacks  primitives  to  represent  the 
context  in  which  deliberations  occur.  For  example,  the 
sources  of  issues  and  the  decisions  that  are  the  outcomes  of 
deliberations  are  not  represented.  REMAP  nodes  and  their 
associated  links  create  an  extensive  model  for  recording 
requirements  engineering  deliberations.  The  model  is  designed 
to  represent  the  iterative  nature  of  requirements  definition 
refinement,  and  their  underlying  rationale,  by  capturing  the 
deliberations  between  stakeholders  (i.e.,  anyone  providing 
input  into  the  specific  decision  being  deliberated) . 
Additionally,  REMAP  provides  traceability  by  relating 
requirements  to  design  objects. 

In  REMAP,  a  REQUIREMENT  is  iteratively  deliberated  and 
refined  using  the  other  primitives  of  the  model.  REQUIREMENTS 
lead  to  DECISIONS  and  DECISIONS  modify  REQUIREMENTS.  Other 
REQUIREMENTS  can  generalize  or  specialize  the  original 
REQUIREMENT.  REQUIREMENTS  generate  ISSUES  which  may  also  be 
suggested  by  ARGUMENTS  and  POSITIONS.  ASSUMPTIONS  qualify 
ARGUMENTS.  DECISIONS  imply  limits  or  CONSTRAINTS  on  the 
output  DESIGN  OBJECT. 
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IV.  IMPLEMENTATION 


A.  GENERAL 

The  implementation  of  REMAP  within  Concept  Demo  was 
accomplished  in  a  truly  iterative  fashion.  We  experienced  a 
steep  learning  curve  at  the  onset,  while  learning  the  various 
software  packages  and  environments.  We  began  with  a  tutorial 
offered  in  the  Concept  Demo  manual.  This  was  followed  by  a 
short  course  at  Andersen  Consulting.  We  learned  the  REFINE™ 
wide  spectrum  language  using  a  computer-aided  training  course. 
Familiarization  with  EMACS,  UNIX,  and  the  Sun  workstation 
environment  itself  was  gained  using  a  "catch-as-catch-can” 
methodology.  The  Concept  Demonstration  User's 

ManualfRef .  27]  proved  invaluable  in  our  efforts  to 
understand  the  system  and  its  code.  The  Refine™  User's 
ManualfRef.  28]  documents  the  capabilities  of  the 
REFINE™  LISP-based  environment. 

In  this  document,  the  following  conventions  are  used: 


NODES 

BOLD  AND  ALL  CAPITAL 

FILE  NAMES 

ITALICIZED  AND  ALL  CAPITAL 

LINKS 

italicized  and  lower  case 

CODE 

italicized,  bold  and  off-set 

FUNCTIONS 

BOLD,  ITALICIZED  AND  ALL  CAPITALS 

MENU  ITEMS 

"bold  and  quotes" 

MANUALS 

Underlined 

EMACS  COMMANDS 

CAPITAL.  ITALICIZED  AND  UNDERLINED 
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This  chapter  will  provide  a  brief  system  description,  followed 
by  a  more  detailed  look  at  the  actual  system  development 
process.  A  REMAP/CD  tutorial  will  follow  and  provide  a  brief 
look  at  an  example  of  all  functionalities. 

h.  REMAP/CD  SYSTEM  DESCRIPTION 

1 .  HARDWARE 

Due  to  licensing  restrictions,  we  implemented  the 
REMAP  model  on  a  SPARC  2  workstation  equipped  with  48 
megabytes  of  RAM.  This  was  an  important  constraint  in  our 
work  as  previous  work  in  the  Concept  Demo  with  32  megabytes  of 
RAM  led  to  the  machine  locking  up. 

2 .  SOFTWARE 

We  used  the  UNIX/SUN  OS  4.1.1  as  our  operating  system, 
with  its  support  for  OPEN  WINDOWS  version  2  windowing 
software.  In  addition,  we  used  the  GNU  EMACS  18.55.0  text 
editor  extended  with  macros  to  run  Common  Lisp  and  REFINE™ 
environments . 

C.  IMPLEMENTATION  TUTORIAL 

1.  BEGINNING  A  NEW  SESSION 

At  this  point,  we  assume  that  you  are  able  to  call  up 
the  Concept  Demo.  Within  the  EMACs  buffer,  type  M-X  RUN-A- 
REFINE .  The  system  will  load  the  REFINE  environment.  The 
version  of  Concept  Demo  that  we  used  is  kbsa-cd-fv-pm-1-3  as 
received  from  Andersen  Consulting.  From  within  the  *SCRATCH* 
buffer  in  REFINE™,  to  load  SAMPLE-LOAD  .LISP  into  the 

buffer  and  compile  using  the  M-X  REFINE-COMPILE-BUFFER 
command.  In  the  *REFINE*  buffer,  at  the  prompt,  type 
(user: : load-sample) <RET>.  The  extensions  are  now  loaded  in 
the  order  previously  described. 


17 


From  within  the  Concept  Demo  program,  mouse  left  on 
the  Knowledge-base  button  in  the  command  menu.  A  pull-down 
menu  will  appear  with  several  options.  Mouse  left  on  the 
"Graph-Used-By-Relations"  menu  item.  This  creates  a  window  of 
the  systems  current  knowledge-based  modules.  Mouse  left  on 
Aircraft-Domain-Spec.  Another  pull-down  menu  will  appear, 
from  this  menu  mouse  left  on  "Graph  REMAP  Model".  A  blank 
screen  with  REMAP  Model  For  KB-module  at  the  top  should 
appear.  Left  mouse  anywhere  on  the  screen  to  reveal  the 
••Semantic  Net  Window  Options'*  menu.  Left  mouse  on  ••Add 
Informal  object".  The  menu  that  appears  will  display  any  of 
the  eight  REMAP  nodes  that  you  can  create.  Mouse  left  on  the 
REMAP-ISSUE  node.  An  input  box  will  appear  to  allow  you  to 
name  the  node  if  you  wish.  Delete  allows  you  to  clear  the  box 
and  enter  the  appropriate  name  for  your  REMAP-ISSDE.  Hit  <RET> 
when  complete.  Now  a  box  appears  to  add  any  appropriate  text 
for  this  REMAP-ISSUE.  When  complete  type  If  the  node 
does  not  appear,  mouse  right  on  an  open  space  of  the  screen 
and  mouse  left  on  "Zoom  Out".  Mouse  left  at  a  point  upper 
left  to  the  node  and  move  the  lower  right  hand  corner  of  the 
grid  to  include  the  completed  node  within  the  grid.  The  blue, 
rectangular  node  will  now  appear  on  the  screen.  You  may  now 
create  more  nodes.  Each  addition  of  an  informal  node  will 
require  you  to  name  the  node  and  to  provide  more  detailed 
information  about  the  node  in  a  text  box  provided.  Each 
pulldown  screen  query  provides  a  default  answer  to  instantiate 
the  node.  For  this  tutorial,  mouse  left  on  any  open  space  and 
create  an  REMAP-ARGUMENT  node.  A  rectangular,  turquoise  node 
appears.  Menu  choices  defined  for  hypertext  nodes  is 
available  for  the  node.  For  example,  right  click  on  the 
REMAP-ARGUMENT  and  select  move.  This  will  allow  the  user  to 
place  the  node  in  a  convenient  position. 
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At  this  point  you  may  add  links  to  the  nodes.  Mouse 
left  on  the  REMAP-ISSUE  node.  A  pulldown  menu  will  appear, 
select  "Add  Link".  Another  menu  will  appear  that  will  provide 
all  the  possible  outgoing  links  for  the  node  you  selected. 
Choose  issue- is-suggested-by-argument ,  and  select  the  node 
that  this  REMAP-ISSUE  should  point  to  by  clicking  left  on 
REMAP-ARGUMEMT .  A  link  label,  ISSnE-SUGGESTED-BY-ARGUMENT: 1 , 
is  created  with  a  default  certainty  of  1  established. 

2 .  LINK  CERTAINTY 

We  have  implemented  an  attribute  to  links  called 
CERTAINTY.  This  attribute  gives  us  a  weighting  scale  from 
zero  to  ten  for  each  link.  To  modify  the  CERTAINTY  of  a 
link,  mouse  left  on  that  link  and  a  menu  will  appear.  Select 
"Modify  CERTAINTY"  from  the  list  and  a  new  menu  will  appear  to 
add  a  value  of  ZERO  through  TEN.  Mouse  left  on  the  value  you 
desire  to  assign  to  the  link.  The  screen  will  automatically 
refresh  and  display  your  CERTAINTY  value  with  the  link. 

3 .  NODE  CERTAINTY 

Each  node  also  contains  a  certainty  value  that  could 
represent  the  strength  of  a  REMAP-ARGUMENT  or  the  belief  of  an 
REMAP-ASSUMPTION.  The  certainty  value  is  color-coded  in  the 
REMAP-ASSUMPTION  node.  For  demonstration,  mouse  left  on  any 
open  space.  Select  "Add  Informal  Object"  and  select  REMAP- 
ASSUMPTION  from  the  menu  that  follows.  Continue  as  previously 
described  to  complete  the  node.  A  yellow  REMAP-ASSUMPTION 
diamond  is  created,  the  default  value  being  1.5  for  node 
certainty.  To  view  the  certainty  value  color  functionality, 
mouse  left  on  the  yellow  REMAP-ASSUMPTION  node,  select  "Modify 
Mode  Certainty"  from  the  menu  that  appears.  Select  node 
certainty  of  0.5  and  note  the  yellow  REMAP-ASSUMPTION  node 
changes  to  red,  representing  a  node  certainty  of  less  than 
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1.0.  This  procedure  can  be  repeated,  and  the  selection  of  a 
value  greater  than  2.0  will  create  a  green  node. 

4.  ADDITIONAL  MENU  OPTIONS 

Four  additional  menu  items  within  the  "Options  For 
REMAP-NODES"  menu  were  added  to  demonstrate  the  ability  to 
call  remote  functions  and/or  programs.  "Show  REMAP  Model" 
displays  a  representation  of  the  generic  REMAP  model  within  an 
XWINDOW  window.  "CUCKOO"  calls  an  audio  program  for 
demonstration  purposes.  "Show  Multimedia"  makes  an  external 
call  to  a  multimedia  program  that  could  represent  a  REMAP- 
ARGDMENT,  for  example.  "Call  EMACS"  allows  us  to  call  an 
external  program  and  with  EMACS  specifically,  to  create 
extended  text  concerning  a  REMAP  node. 

5.  CAPTURING  DELIBERATIONS  DATA 

Recalling  from  Chapter  III,  we  have  certain  REMAP- 
REQUIREMENTs  to  achieve  when  creating  software.  From  these 
REMAP-REQDIREMENTS  certain  REMAP-ISSDEs  may  arise  that  could 
lead  to  different  courses  of  action.  This  could  further  lead 
to  supporting  and  opposing  REMAP-ARGDMENTs  to  the  REMAP-ISSUE. 
REMAP-ASSUMPTIONs  Could  lead  to  Our  REMAP -ARGUMENTS  for  or 
against.  As  each  new  node  arises  within  the  deliberation,  we 
create  and  name  the  node  to  reflect  the  key  concept  and  also 
provide  textual  elaboration  of  that  node.  Additional  nodes 
and  links  are  created  and  related  in  a  similar  fashion. 

D.  IMPLEMENTATION 

1 .  APPROACH 

Previously,  we  described  how  to  use  the  system.  We 
will  now  discuss  the  details  of  our  implementation.  The 
initial  approach  to  accomplishing  the  implementation  of  REMAP 
within  the  Concept  Demo  involved  extensive  re-use  of  existing 
functions.  We  modified  functions  that  had  been  used  to 
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partially  implement  the  IBIS  model  into  the  Concept  Demo. 
These  functions  were  fairly  easy  to  locate  using  the  EMACS 
text  editor.  The  M- .  command  proved  invaluable  allowing  the 
trace  of  existing  functions  throughout  the  system.  We  were 
then  able  to  evaluate  the  use  of  different  functions  and 
determine  how  they  could  be  reused  for  our  implementation. 
This  method  was  successful  for  the  initial  implementation  of 
a  basic  graphical  browser  to  instantiate  REMAP  nodes  and  links 
within  the  Concept  Demo.  As  worked  progressed  and  the 
implementation  of  new  functionality  became  essential,  new  code 
had  to  be  written. 

In  order  to  facilitate  compilation  of  files  with  REMAP 
code,  we  created  a  file  called  SAMPLE-LOAD. LISP. (Appendix  A) 
The  EMACS  command  M-X  REFINE-COMPILE-BUFFER  is  used  to  compile 
the  buffer  containing  the  file  and  then  the  function 
'  (USER: : SAMPLE-LOAD)  *  is  used  on  the  command  line  in  the 
*REFINE*  buffer.  All  the  files  that  have  been  listed  into 
SAMPLE-LOAD .LISP  are  now  compiled  in  the  appropriate  order. 
This  procedure  compiles  and  loads  the  last  saved  version  of 
the  listed  files.  If  a  file  is  loaded  in  an  EMACS  buffer,  and 
if  changes  have  been  saved,  when  you  compile  the  SAMPLE¬ 
LOAD.  LISP  buffer  with  the  M-X  REFINE-COMPILE-BUFFER  command, 
you  will  see  a  message  in  the  *REFINE*  buffer  stating  that  the 
current  version  of  the  file  that  you  have  modified  has  not 
been  compiled,  but  that  the  system  will  recompile  the  changed 
file  for  you  and  create  a  fast-loading (. fasl)  version.  The 
advantage  of  using  the  SAMPLE-LOAD. LISP  file  is  that  instead 
of  loading  each  listed  file  into  a  buffer  and  compiling  that 
buffer,  only  a  couple  of  simple  steps  are  required. 

Individual  functions  within  the  EMACS  editor  can  be 
compiled  by  placing  the  cursor  within  any  portion  of  the 
function  you  would  like  to  compile  and  executing  the  ^C-^C 
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command.  Vs  method  is  useful  to  check  the  correctness  of 
modifications  of  work  in  progress.  To  compile  a  file,  you  must 
first  load  that  file  into  a  buffer.  This  is  accomplished  by 
using  the  EMACs  command  and  then  entering  the  name  of 
the  file  you  would  like  to  enter  into  the  buffer.  The  buffer 
created  is  automatically  named  the  same  as  the  file  you  just 
entered.  Now  you  are  able  to  compile  the  entire  buffer  using 
the  EMACs  command  M~X  REFINE-COMPTLE-BUFFER.  This  method  is 
useful  when  several  functions  need  compiling  within  the  same 
buffer. 

2 .  DEFINING  VARIABLES 

The  first  step  in  extending  the  Concept  Demo  involved 
the  creation  of  appropriate  variables  corresponding  to  the 
REMAP  model.  To  avoid  confusion  with  previously  set 
variables,  the  name  of  each  variable  to  define  a  REMAP  node  is 
started  with  "REMAP" { i . e . ,  REMAP-ISSUE).  A  patch  to  the 
original  HYPERTEXT .RE  file  written  for  the  Concept  Demo  called 
HYPERTEXT-PATCH .RE  contains  these  definitions.  Each  node  of 
the  REMAP  model  is  represented  a  variable  within  the  system. 
The  variables  for  the  REMAP  model  are  defined  in  the  following 
format: 


var  remap-issue:  object-class  subtype-of  remap-node 

The  super-class  remap-node  is  also  defined  within  the  same 
file: 

var  remap-node:  object-class  subtype-of  hypertext-node 

The  variable  hypertext-node  was  previously  defined  within  the 
HYPERTEXT. RE  file. 
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For  each  REMAP-NODE  an  attribute  called  node-certainty 
is  then  defined.  This  definition  allows  a  real  value  to  be 
assigned  which  could  be  used  to  signify,  for  instance,  the 
belief  in  an  ASSUMPTION  node,  or  the  certainty  of  an  ARGUMENT 
node. 


The  current  implementation  limits  values  for  node 
certainty  to  zero  through  3.0.  This  can  easily  be  modified  to 
fit  the  user's  needs  through  MODIFY-NODE-CERTAINTY  in  GRAPH - 
SN -MODEL-PATCH .RE .  The  following  code  defines  the  variable 
node-certainty  and  includes  a  rule  that  computes  the  node¬ 
certainty  for  a  REMAP-POSITION  based  on  the  average  of  the 
node-certaintys  of  REMAP-ARGUMENTs  that  support  it. 

var  node-certainty:  map (remap-node,  real) 
computed  using 

remap-position  (p)  &  'empty  (argument-supports- 

position  (p) )  =>  node-certainty  (p)  = 
reduce  (+, image  (node-certainty,  argument-supports- 
position(p) ) )  /  size  (argument-supports- 

position(p)  )  , 

true  =>  node-certainty (§§)  -  1.5 

Our  next  step  within  this  same  file  is  to  define  the 
links  between  the  REMAP-NODES.  As  an  aid  in  understanding  the 
REMAP  model,  we  included  the  name  of  the  link  and  the  nodes 
that  the  link  connects  in  the  variable  name.  An  example  of  a 
link  definition  looks  like  this: 

var  issue— suggested-by— position:  map (remap-issue,  set 
(remap-position) ) 

computed-using  issue-suggested-by-position(§§)  —  {} 
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The  variable  issue-suggested-by~position  is  a  map  of  a  REMAP- 
ISSUE  onto  a  set  of  REMAP-POSITIOM.  The  (@0)  is  the  default 
function  used  as  a  wildcard  in  patterns  to  fill  out  mandatory 
parts  of  the  syntax  of  an  object  class. [Ref.  29] 

When  the  variables  are  created,  we  needed  a  method  to 
export  these  variables  into  the  system  'CD  package.  This  was 
done  utilizing  a  REFINE™  form.  The  following  form  exports 
REMAP-MODE,  REMAP-ISSUE,  and  issue-suggested-by~position  and 
other  links  and  nodes  mentioned  in  it. 

form  export-hypertext-patch 

export  ({• remap-node,  • remap-issue,  • issue-suggested- 
by-position, . . .  }, 

•cd); 

3 .  REMAP  DISPLAY 

The  next  logical  step  was  to  incorporate  the  REMAP 
model  components  in  menus  so  that  we  could  create  nodes  and 
their  links  on  a  graphical  browser.  The  file  GRAPH-SN-MODEL- 
PATCH.RE  contains  a  majority  of  the  code  for  menu  creation. 
The  first  item  we  concern  ourselves  with  is  the  creation  of 
informal  objects (REMAP-NODES) ,  within  the  system.  Informal 
objects  are  objects  that  have  a  informal  component  such  as 
text.  This  is  done  in  a  function  called  ADD- INFORMAL-OBJECT. 
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As  can  be  seen  below,  this  function  checks  whether  the  objects 
we  intend  to  modify  is  a  REMAP-NODE: 

/unction  add-informal -object  (dw:  diagram-window;  = 
let  ( in formal-obj -class-names:  set (symbol)  = 
image ^name, class-subclasses 
(find-object-class  (•  remap-node)  ,  time)  )  ) 
let (ht-cl ass-name:  symbol  = 

single-menu ("Choose  the  type  of  Informal  Object", 
informal -obj -class-names, 

* ; : display- function,  • string-capital ize, 

* ; : moving?,  false, * : : abort-value,  *abort-value* ) ) 
user-create-instance( find-object-class 
(ht-class-name)  , 
diagram-windotf -spec-module  (dw)  ) 

Next  we  provided  a  method  to  initialize  an  instance  of 
the  type  of  node  selected.  The  following  initializes  a  REMAP- 
ISSUE: 

Method  user-initialize-new-instance  (obj:  remap-issue, 

kbm:  kb-module)  = 

edi t-hyperstring (obj ) ; 

add-informal -functional-requirement-hlec (obj , kbm) 

It  is  relatively  straight  forward  to  add  an  informal 
object.  Any  REMAP  node  can  be  selected  from  the  menu  to  be 
instantiated  as  an  informal  object.  The  next  subsection  will 
describe  how  the  nodes  appear  on  screen. 


Now  that  a  node  called  REMAP-ISSDE  has  been  created, 
a  menu  that  displays  those  options  that  are  available  for  use 
with  that  new  node  is  available.  There  are  three  components 
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that  allow  display  of  those  options.  First,  a  method  called 
MOOSE-’LEFT-METHOD  has  been  specialized  for  each  RENAP*>NODE. 
This  enables  the  user  to  click  on  the  node  and  invoke  a  menu. 
An  example  for  the  REMAP-I88UE  looks  like  this: 

method  MOOSE-LEFT-HETHOD 

(obj :  cd: : remap-issue, p, v) = 
active te-cd-menu ( *menu-for-i ssues*, 

•  mouse-left, obj , p, w) 

This  method  calls  a  variable  called  *menu-for-issue*,  so  we 
precede  this  method  with  the  variable  statement  shown  below: 

var  *menu-for-issue*  : menu-object  = 

make-menu-object ("Options  for  Issue  Node", 
Combine-items ([ * sn-objects-menu- items* , 

* informal -objects -menu -i terns * , 

* issue-menu-items* ] ) , 

•  cd:  :semantic-net-windotr-options) 

This  variable  combines  several  menu  items  as  seen 
above.  The  first  two  items  in  this  list  are  generic  Concept 
Demo  variables.  The  third  item  {* issue-menu-items*)  adds 
those  options  that  we  considered  pertinent  to  the  REMAP-I88UE. 
Below  is  a  sample  of  the  menu  items  we  created  for  the  REMAP- 
ISSUE  node  of  the  model.  These  will  be  more  fully  explained 
in  the  tutorial  section. 
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var  *remap-issue-menu-items* :  any- type  = 

«"Call  EMACS",  (lambda  (b,o,p,w) 

excl : :  rxm-^shel  1 -command  ("  /usr/ local /bin/ emacs"  )  }  >, 
<"Shotf  multi-media",  (lambda  (b,o,p,w) 
excl : : run-shell-command 
(string (format (false, 

" /usr/openwin/bin/pageview/ files /isl /remap/ figures/  ~a)  ))> 
<" Cuckoo" ,  (lambda,  (b,o,p,w) 
excl : : run-shell-command 

(" /usr/ demo /SOUND /cuckoo. clock" ) ) » 

In  the  file  VIEWABLE-SLOTS-PATCH .RE ,  a  variable  called 
*viewable-slots-for-hypertext*  is  defined.  This  provides  the 
legal  slot  definitions  for  all  hypertext  nodes  (such  as  REMAP- 
NODES)  or  complains  to  the  system  when  an  undefined  attribute 
is  found.  We  have  extended  the  definition  of  this  variable  to 
include  REMAP  specific  attributes,  such  as  issue-replaces- 
issue,  as  follows: 

var  cd-ui : : *viewable-slots-for-hypertext* 

:set (re: : binding)  = 

{ find-attribute-or-complain ( • issue-replaces-issue) , 
find-attribute-or-complain ( ' issue-questions-issue) } 

The  general  construct  re::binding  used  here,  refers  to 
REFINE'S™  uniform  treatment  of  constructs  that  introduce 
named  entities,  such  as  variables,  constants  and 
types. [Ref.  30] 

The  VIEWABLE-SLOTS-PATCH .RE  file  also  identifies  the 
specific  viewable  slots  for  node  menu  items(i.e.,  REMAP- 
ISSUE)  .  The  format  for  this  definition  is  the  same  as  above. 
For  instance,  all  the  possible  links  from  an  REMAP-ISSUE  node 
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are  grouped  into  the  *viewable-slots-for-remap-issue* 
variable. 

In  order  to  utilize  the  functions  already  established 
in  VIEWABLE-SLOTS  .RE ,  we  need  to  add  our  definition  of 
viewable-slots  for  each  specific  node-primitive.  This  is 
accomplished  in  a  variable  definition  called  viewable-slots . 
The  definition  looks  like  this: 

var  viewable-slots:  map (re :: universe,  set (re: : binding ) ) 
computed-using 

remap-issue (X)  =>  viewable-slots (x)  = 
*viewable-slots-for-rema p-issue* , 


4.  ADDING  ATTRIBUTES  TO  ATTRIBUTES  (FACETS) 

In  a  manner  similar  to  certainty  for  nodes,  a 
certainty  value  for  links  was  incorporated.  This  could 
represent,  for  example,  a  relative  strength  of  a  link  such  as 
argument-depends-on-assumption.  This  task  proved  very 
challenging  in  comparison  to  adding  a  certainty  value  to 
nodes . 


The  links  in  the  REMAP/CD  are  REFINE™  maps  from  one 
REMAP-NODE  to  another  set  of  appropriate  REMAP-NODES,  as 
described  earlier  under  DEFINING  VARIABLES.  (Chapter  IV.  C. 
2.)  Since  the  domain  type  of  a  map  can  only  be  simple 
REFINE™  data  types  (i.e.,  string  or  integer) 
[Ref.  31],  directly  mapping  a  certainty  value  to  a 
link,  which  is  not  a  simple  data  type,  is  not  possible.  One 
of  the  creators  of  CD  suggested  a  brilliant  work  around.  This 
"map  to  a  map"  extension  is  represented  in  appendix  G  and 
henceforth  referred  to  as  a  facet- 
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The  first  step  in  incorporating  facets  was  creating  a 
new  class  called  attribute-instance.  Two  related  variables 
were  also  created: 

var  attribute-instance:  object-class  subtype-of  user- 
object 

var  attribute- instance-target:  map  (attribute- instance, 
re: :universe)  =  {\\} 

var  attribute- instance-attribute :  map (attribute- 

instance,  re: : binding)  =  {\\} 

The  new  class  attribute-instance  represents  a 
particular  value  of  an  attribute  for  a  class.  The  attribute- 
instance-target  maps  the  attribute-instance  to  the  REMAP-NODE 
from  which  the  link  originates,  and  attribute- instance- 
attribute  maps  the  attribute-instance  to  the  REMAP  link. 

Facets  are  further  explained  through  the  function 
calls  that  use  them  to  modify  an  attribute's  certainty. 
Mousing  left  on  a  link  makes  available  the  menu  option  "ADD 
CERTAINTY".  This  activates  the  function  INVOKE- ADD- ATTRIBOTE- 
CERTAINTY  (see  also  GRAPH-SN-MODEL-PATCH .RE {appendix  D)  )  as 
below: 

function  invoke-add-attribute-certainty (button:  symbol, 
obj:  object,  pos:  point,  N:windov)  = 

let (new-certainty :  integer:  =  ri: : single-menu ("Select 
Certainty",  [0,1, 2, 3, 4, 5, 6, 7, 8, 9, 10] ) ) 

let(ai-target:  re: :universe  =  attribute-instance- 

target  (obj ) , 
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attribute-instance- 


ai-attribute:  re: zbinding  = 
attribute (obj ) , 
let (source-icon:  icon  = 

find-existing-icoi'i-for-spec-object  (ai-target,  ai- 
attribute,  • cd: : certainty,  new-certainty) ; 
erase-object (obj ) ; 
update-sn-object ( sour ce-i con, w) 

The  obj:  object  is  the  attribute-instance  of  the  link 
that  was  moused  on.  First,  a  certainty  value  is  entered  at 
the  screen,  by  selecting  an  integer.  The  range  of  values  that 
can  be  assigned  can  be  change  easily  by  including  an 
appropriate  set  for  "new-certainty"  defined  above.  Ai-target 
and  ai-attribute  are  set  to  the  value  of  the  REMAP-NODE  and 
the  link  of  the  attribute  instance,  respectively.  In 
FACETS .RE ,  Store-attribute- facet  is  called  with  the 
appropriate  input.  A  facet  named  "certainty"  is  created  by 
the  above  procedure.  A  similar  procedure  can  be  used  for 
creating  other  facets.  The  relevant  code  that  follows  are 
shown  in  FACETS  .RE  and  can  be  traced  by  the  interested  reader. 
Here,  the  REMAP  link  and  the  facet  name,  certainty  currently, 
are  combined  to  create  a  matching  link  that  has  the  certainty 
value  attached.  For  the  user,  the  certainty  value  appears 
mapped  to  the  link,  but,  in  fact,  a  map  is  attached  to  the 
REMAP-NODE,  that  is,  the  attribute-instance-target . 

After  completion  of  this  process  and  returning  back  to 
the  original  function,  the  old  object  is  erased,  and  a  new 
icon  representing  the  link  and  new  certainty  value  is  then 
drawn.  This  is  done  through  the  HAKE-LABBL-FOR-SN-CERTAINTY 
function. 
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5 .  INTEGRATION 

All  the  variable  definitions  and  functions  described 
previously  are  used  by  functions  defined  in  a  file  called 
GRAPH-IBIS-MODEL-PATCH .RE .  Our  implementation  includes 
several  functions  to  create  a  graphical  browser  for  REMAP. 
The  first  function  is  called  GRAPH-REMAP-MODEL.  This  function 
allows  us  to  graph  the  basic  REMAP  primitives.  The  function 
also  identifies  the  allowable  variables  to  be  manipulated. 
This  function  is  called  when  you  mouse  left  on  a  knowledge¬ 
base  module  within  the  "Graph-Used-by-Relatlons"  diagram: 

function  graph-remap-model  (objs:  set (re: : universe ) , 
title-string:  string)  = 

graph-basic-sn-model (objs,  find-attributes  or  complain 
( { ' issue-replaces-issue, * issue-questions-issue, 
'...etc...;;,  title-string) ; 
let  (dw:  diagram-windov  -make-object  ( ‘  diagram-window)  , 
surf:  diagram-surface  =  make-object ( ' diagram-surface) ) 

The  function  GRAPH-REMAP-MODEL-FOR-MODULE  identifies 
the  REMAP  primitive  nodes  as  KB  module  objects: 

function  graph-remap-model-for-module  (kbm:  kb-module)  = 
let  (remap-nodes:  set (remap-node)  =  {x\  (x)  x  in 
owned-object (kbm)  &  remap-node (x) }) 

Also  within  GRAPH- IBIS-MODEL-PATCH .RE  are  two 
functions  that  manipulate  the  shape  and  color  of  the  various 
REMAP-NODEs.  This  functionality  allows  the  user  an  easier 
means  to  differentiate  the  various  types  of  nodes  defined  in 
REMAP  or  to  display  a  node  in  different  colors  depending  on 
the  value  of  an  attribute.  The  function  FIND-SHAPE-FOR-SN- 
ICON  uses  a  series  of  simple  if-elseif  statements  to  represent 
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all  IBIS  nodes  as  boxes,  a  REMAP-A8SUMPTIOM  as  a  diamond,  and 
all  other  REMAP  nodes  as  ellipses.  The  code  follows: 

function  find-shape-for~sn-icon(obj:  object)  zsymbol^ 
if  remap-position (obj)  then  'ri::box 
elseif  remap-issue (obj }  then  ’rizzbox 
elseif  remap-argument (obj)  then  'rizzbox 
elseif  remap-assumpti on (obj )  then  'riz  zdi amond 
else  'riz  zellipse 

The  second  function,  FIND-COLOR-FOR-SN-ICON ,  adds 
color  to  each  of  the  nodes.  With  the  REMAP'-ASSUHPTIOM  node 
however,  increased  functionality  is  demonstrated  with  an 
additional  if-elseif  statement  embedded  within  the  first. 
REMAP-ASSUMPTIOM  is  created  as  a  diamond  and  the  additional 
ability  to  change  icon  colors  based  on  certainty  value  is 
provided.  The  following  code  demonstrates  how  a  node  is 
colored: 

function  find-color-for-sn-icon(objz  object)  zsymbol  »= 
let  (cert  z  real  node-certainty  (obj)  ) 

if  remap-position  (obj)  then  ctrz  zmagenta 
elseif  remap-argument (obj )  then  cwz  z turquoise 

...  etc ... 

elseif  remap-assumption (obj )  then 
if  cert  <=  1.0  then  cwzzred 

elseif  cert  >  1.0  and  cert  <"‘2.0  then  yellotf 
else  cwz  zgreen 
else  cwzzwhite 

These  functions  demonstrate  a  means  to  Implement  rules 
within  the  REMAP  model  using  shapes  and  colors  to  visually 
identify  values. 
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Of  key  importance  to  integration  within  the  KBSA 
framework,  are  high-level  editing  commands  (HLECs) .  The  file 
HLEC-PATCH .RE  contains  one  such  example.  The  format  is  more 
fully  explained  in  the  Concept  Demo  User's  Manual.  When  a 
node's  certainty  is  changed,  for  example,  more  than  stored 
value  of  real  number  must  change.  If  that  node  is  REMAP- 
ASSUMPTION,  the  icon  that  represents  the  node  may  have  to 
change  colors.  HLECs  enable  the  system  as  a  whole  to  be  made 
aware  of  the  change,  so  that  all  other  affected  areas  are  also 
changed  accordingly. 
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VI .  RECOMMENDATIONS 


A.  COMMENTS 

There  was  a  steep  learning  curve  to  overcome  in  this 
implementation.  Numerous  software  packages  were  encountered 
for  the  first  time  by  us.  Obviously,  the  more  experience  the 
user  has  in  the  underlying  environments,  the  easier  an 
implementation  such  as  ours  will  be.  The  REFINE™  environment 
is  based  on  common  lisp.  The  documentation  is  reasonably  well 
written.  A  CAI  system  provided  with  the  package  was  a  great 
starting  point  for  our  work.  As  noted  in  the  discussion  on 
facets,  the  REFINE™  language  has  some  shortcomings  as  an 
object  oriented  language.  However,  REFINE^*^  has  the 
functionality  to  satisfy  our  requirements.  The  graphical 
support  in  the  REFINE™  environment  provides  excellent  layout 
features,  but  it  has  limited  capability  for  displaying  objects 
in  different  colors  and  shapes  as  required  in  our  work. 

With  the  extensive  functionality  that  results  from  an 
environment  like  REFINE™  and  Concept  Demo  comes  complexity. 
The  CD  tutorial  and  user’s  manual  were  pieced  together  with 
the  generous  help  of  one  of  the  authors  of  Concept  Demo. 
Without  this  help,  the  learning  process  would  have  been  much 
slower  and  very  difficult. 

B.  FUTURE  INITIATIVES 

1.  EASE  OF  USE 

The  primary  design  objective  in  our  effort  has  been 
ease-of-use  for  the  end-users.  The  end-user  must  easily  be 
able  to  enter  deliberation  information,  and  conduct 
conversations  with  other  participants.  The  user  should  be 
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able  to  enter,  organize  and  retrieve  design  deliberation 
information  with  minimal  training  on  the  system.  The  current 
implementation  is  only  partially  successful  in  this  respect. 
Future  work  emphasizing  "user-friendliness"  would  be  a 
definite  benefit.  The  following  subsections  include  areas  for 
consideration . 

a .  INPUT 

An  alternate  interface  which  accepts  textual 
representation  of  the  REMAP  nodes  and  links,  could  be  very 
useful  for  "off  line"  capture  of  conversations  without  much 
intrusion  into  a  deliberation  session.  For  example,  during  a 
planning  meeting,  a  scribe  can  quickly  record,  in  textual 
format,  pertinent  deliberation  data  in  terms  of  REMAP 
primitives.  The  system  should  be  able  to  parse  the  text  and 
develop  the  appropriate  information  in  the  knowledge  base. 

Jb.  EASE  OF  UNDERSTANDING 

The  deliberations  information  should  be  displayed 
in  a  manner  that  allows  for  easy  understanding. 
Realistically,  we  believe  that  the  user  will  have  to 
understand  the  concept  behind  the  REMAP  model  and  the  logical 
progression  of  information  development  through  the  REMAP 
paradigm.  With  some  basic  knowledge  of  the  REMAP  method,  the 
user  would  benefit  from  visual  cues  provided  by  the 
implementation  itself  which  would  include  judicious  use  of 
color  and  shape  to  differentiate  nodes  of  the  model  and  the 
perceived  weight  given  to  each  node  and/or  link. 

An  additional  node  menu  option  could  be 
incorporated  that  would  present  a  color  coded  version  of  the 
REMAP  model  with  help  facilities  that  describe  the  model 
components  and  provides  a  comprehensive  example.  This  would 
help  in  the  early  stages  of  use  as  additional  knowledge  is 
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gained  with  the  use  of  the  model  and  its  deliberation 
capturing  ability.  A  color  coded  legend  could  easily  be  added 
that  would  change  color  to  match  the  node  that  the  pointer  is 
in,  and  display  appropriate  options  for  that  node. 

c.  EASE  OF  INFORMATION  RETRIEVAL 

In  large  complex  problems,  the  number  of  REMAP 
nodes  and  links  may  be  extremely  large  and  the  user  may  be 
overwhelmed.  The  user  should  have  an  option  for  limiting  the 
amount  of  information  that  is  presented.  For  instance,  a 
manager  might  want  to  limit  his  view  to  REMAP-ISSUEs  that  are 
unresolved  to  identify  problem  areas  for  project  planning  and 
monitoring.  Mechanisms  to  provide  aggregate  views  of  a 
network  of  nodes  could  be  used  to  provide  a  high  level  view  of 
the  deliberation  information.  The  aggregate  nodes  could  be 
exploded  to  provide  lower  level  details.  Additionally, 
filtering  and  query  mechanisms  can  be  setup  to  selectively 
retrieve  information  pertaining  to  topics  of  interest. 

2.  EASE  OF  CAPTURE 

Multimedia  advances  have  made  it  possible  to 
incorporate  detailed  accounts  of  deliberation  activities  in 
terms  of  the  REMAP  model.  Video  and  voice  clips  could  be 
attached  to  a  REMAP  node  instead  of,  or  to  enhance  the  textual 
support  already  provided  by  the  system.  These  facilities 
would  greatly  enhance  the  ease  of  capture  of  deliberation 
information  with  minimal  intervention. 

3.  DECISION  SUPPORT 

As  the  information  in  the  knowledge  base  has  a  formal 
representation,  reasoning  with  this  knowledge  can  be  performed 
to  support  various  stakeholders.  For  instance,  domain  and 
task  specific  deductive  rules  can  be  set  up  to  provide 
automated  inference.  An  example  of  such  a  rule  would  be  one 
that  uses  the  strengths  of  ASSUMPTION  and  the  degree  of 
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support  they  provide  to  ARGUMENTS  in  computing  the  strength  of 
belief  in  ARGUMENTS.  This  information,  in  turn,  can  be  used 
in  evaluating  POSITIONS  that  respond  to  ISSUES. 


4 .  SECURITY 

Security  is  not  currently  addressed  in  this  prototype 
system.  Any  actual  use  of  the  system  would,  of  course,  have 
to  take  this  into  serious  consideration.  Appropriate  access 
(read/write)  permission  schemes  should  be  developed.  Also, 
the  means  to  allow  for  "invisible"  deliberations  (e.g., 
between  two  upper-level  managers  that  is  not  visible  to  lower 
level  employees)  would  be  very  useful. 
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APPENDIX  A 


A. 


NPS-KB-MODULE-LIBRARY . RE 
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!!  in-package ("CD") 

! !  in-grairanar ( '  kb-module-grammar) 

%%  Local  library  directory  is  set  here. 

the-kb-module  agl-ibis-nodes 
uses-kb-modules  (upper-model) 
kb-module-path  "/files/isl/remap/extend/" 


APPENDIX  B 


A. 


SAMPLB'LOAD. LISP 
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(in-package  'USER) 


; ;  This  file  compiles  those  files  necessary  to  iuplement 
; ;  REMAP  within  the  Concept  Demo . 

; ;  change  the  following  function  to  match  your  specific  site. 

(defun  sanple-path  (file-name) 

(concatenate  'string  "/files/isl/remap/extend/"  file-name)) 


(defun  load-sample  () 

(cload  (scut^jle-path  "hypertext-patch")) 

(cload  (.saii5>le-path  "facets")) 

(cload  (sanpie-path  "hlec-patch" ) ) 

(cload  (sanple-path  "graph-ibis-model-patch") ) 
(cload  (sample-path  "graph-sn-model-patch") ) 
(cload  (sample-path  "viewable-slots-patch") ) 
(cload  (sample-path  "nps-kb-module-library"> ) 

) 


A. 


appendix  c 

KYPERTEXT-PATCH . RE 
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!  !  in-package ( " CD " ) 
!!  in-grammar (' user) 


%%  This  file  contains  the  variables  for  the  REMAP  model  and  the  slots 
%%  associated  with  those  node  variables.  It  exports  them  and  puts  the  slots 
%%  into  the  viewable  slots. 


var  remap-node:  object-class  subtype-of  hypertext-node 

var  remap-assunption:  object-class  subtype-of  remap-node 
var  remap-constraint:  object-class  subtype-of  remap-node 
var  remap-design-object:  object-class  subtype-of  remap-node 
var  remap-decision:  cbject-class  subtype-of  re;nap-node 
var  remap-recjuirement :  object-class  subtype-of  remap-node 
var  remap-position:  object-class  subtype-of  remap-node 
var  remap-issue:  object-class  subtype-of  reroap-node 
var  remap-argument:  object-class  subtype-of  remap-node 


var  decision-modifies-requirement :  map (remap-decision, set (remap-requirement) ) 
computed-using  decision-modifies-requirement (00)  =  {} 

var  requirement -generalizes-recjuirement :  map (remap- requirement,  set (remap-requirement) ) 
computed-using  requirement-generalizes-requirement (00)  =  (} 

var  requirement-specializes-requirement :  map (remap-requirement,  set (remap-requirement) ) 
conputed-using  requirement-specializes-requirement (00)  =  {} 

var  requirement-generates-issue:  map (remap- requirement,  set (remap-issue) ) 
conputed-using  requirement-generates-issue (00)  =  {) 

var  requirement-leads-to-decision:  map (remap-requirement,  set (remap-decision) ) 
coitputed-using  requirement-leads-to-decision  (00)  =  (} 

var  issue-generalizes-issue:  map (remap-issue,  set (remap-issue) ) 
computed-using  issue-generalizes-issue (00)  =  {} 

var  issue-specializes-issue :  map (remap-issue,  set (remap-issue) ) 
computed-using  issue-specializes-issue (00)  =  i) 

var  issue-replaces-issue:  map (remap-issue,  set (remap-issue) ) 
conputed-using  issue-replaces-issue (00)  =  (} 

var  issue-questions-issue ;  map (remap-issue,  set (remap-issue) ) 
conputed-using  issue-questions-issue (00)  ={} 

var  issue-suggested-by-issue :  map (remap-issue,  set (remap-issue) ) 
conputed-using  issue-suggested-by-issue (00)  =  (} 

var  issue-suggested-by-position:  map (remap-issue,  set (remap-position) ) 
conputed-using  issue-suggested-by-position (00)  =  (} 

var  issue-suggested-by-arg\iment :  map (remap-issue,  set (remap-argument) ) 
conputed-using  issue-suggested-by-argument (00)  =  (} 

var  position-responds-to-issue:  map (remap-position,  set (remap-issue) ) 
conputed-using  position-responds-to-issue (00)  =  {) 

var  argument-supports-position:  map (remap-argument,  set (remap-position) ) 
conputed-using  argument-supports-position (00)  =  {} 

var  argument-objects-to-position:  map (remap-argument,  set (remap-position) ) 
conputed-using  argument-objects-to-position (00)  =  {} 


var  argument-depends-on-assuirption :  map (remap-argument,  set (remap- assumption) ) 
computed-using  argument-depends-on-assunption (@@)  *  (} 

var  assumption-qualifies-argximent :  map  (remap-assunption,  set  (remap-argxunent) ) 
conputed-using  assumption-qualifies-argiunent (00)  “  (} 

var  decision-resolves-issue:  map (remap-decision,  set (remap- is sue) ) 
computed-using  decision-resolves-issue (00)  =  () 

var  decision-selects-position:  map (remap-decision,  set (remap-position) ) 
conputed-using  decision-selects-position (00)  =  {} 

var  decision-generalizes-decision:  map (reroap-decision,  set (remap-decision) ) 
computed-using  decision-generalizes-decision (00)  =  {} 

var  decision-specializes-decision:  map (remap-decision,  set (remap-decision) ) 
conputed-using  decision-specializes-decision (00)  =  {} 

var  decision-depends-on-decision :  map (remap-decision,  set (remap-decision) ) 
conputed-using  decision-depends-on-decision (00)  =  (} 

var  decision-inplies-constraint :  map (remap-decision,  set (remap-constraint) ) 
conputed-using  decision-inplies-constraint (00)  *  () 

var  decision-leads-to-constraint :  map (remap-decision,  set (remap-constraint) ) 
conputed-using  decision-leads-to-constraint (00)  =  {} 

var  decision-generates-constraint :  map (remap-decision,  set (remap-constraint) ) 
computed-using  decision-generates-constraint (00)  =  {} 

var  constraint-creates-design-object :  map (remap-constraint,  set (remap-design-object) ) 
conputed-using  constraint-creates-design-ob ject (00)  =  (} 

var  constraint-removes-design-ob ject :  map{remap-constraint,  set (remap-design-object) ) 
conputed-using  constraint-removes-design-ob ject (00)  =  () 

var  constraint-modifies-design-object :  map (remap-constraint,  set (remap-design-object) ) 
conputed-using  constraint-modifies-design-ob ject (00 )  =  {} 

var  design-object-depends-on-constraint :  map (remap-design-object,  set (remap-constraint) ) 
conputed-using  design-object-depends-on-constraint (00)  =  (} 

var  node-certainty:  map (remap-node,  real) 
conputed-using 

remap-position (p)  &  -empty (argument-support s-pos it ion (p) )  => 
node-certainty (p)  = 

reduce (+,  image (node-certainty, argument-supports-position (p) ) )  / 
size (argument-supports-position (p) ) , 
true  =>  node-certainty (00)  =  1.5 


%%  If  any  of  the  below  links,  nodes,  etc.  are  changed,  you  must  go  to 
%%  graph-ibis-model-patch  and  change  the  function  graph-remap-model 

%%  and  graph-remap-model-for-module. 

%% 

form  export -hypertext -patch 

export  ( ( '  remap-node, '  remap-decision, '  remap-constraint, '  remap-design-object, 

'  remap-assun?)tion, '  remap-position, '  remap-issue, '  remap-argiiment , 

' remap-requirement, 

' assurqjtion-certainty, ' node-certainty, 

'  decision-modifies-requirement, ' requirement-generalizes-recjuirement, 
'  requirement-specializes-requirement, '  requirement-generates-issue, 

'  requirement-leads-to-decision, 

'  issue-generalizes-issue, ' issue-specializes-issue, 

'  issue-replaces-issue, ' issue-questions-issue. 


'  issue-suggested-by-issue, ' issue-suggested-by-position, 

'  issue-suggested-by-argument, 'position-responds-to-issue, 

' argument-supports-position, 'argument-ob]ects-to-position, 

'  argument-depends-on-assumption, 

' assumption-qualifies-argument, ' decision-resolves-issue, 

'  decision-selects-position, 

'  decision-generalizes-decision, ' decision-specializes-decision, 

'  decision-depends-on-decision, 

'  decision- implies-constraint, ' decision-leads-to-constraint, 

'  decision-generates-constraint, 

'  constraint-creates-design-ob ject, ' constraint-removes-design-object, 
'  constraint-modif ies-design-ob ject, 

' design-ob ject-depends-on-constraint } , 

'  cd) 
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!  !  in-package ('  cd-ui) 
!!  in-gramtnar  (' gr) 


function  add-inf ormal-object  (dw;  diagram-window)  = 
let (informal-obj-class-names :  set (symbol)  - 

image (name, class-subclasses (find-object-class (' remap-node) ,  true) ) ) 
let (ht-class-name:  symbol  = 

single-menu ("Choose  the  type  of  Informal  Object", 
informal-obj-class-names, 

'  :: display-function,  ' string-capitalize, 

'  : :moving?,  false, ' : :abort-value,  *abort -value*) ) 
user-create-instance (find-object-class (ht-class-neime) , 

diagram-window-spec-module () 


method  user-initialize-new-instance  (obj:  remap-issue, 

kbm:  kb-module)  = 

edit-hyperstring (obj) ; 

add-inf ormal-functional-requirement-hlec (obj, kbm) 


method  user-initialize-new-instance  (obj:  ri::icon, 

kbm :  kb-modu 1 e )  = 

edit-hyperstring (obj) ; 

add-informal-functional-requirement-hlec (obj,  kbm) 


method  user-initialize-new-instance  (obj:  attribute- instance, 

kbm :  kb-modu 1 e )  = 

edit-hyperstring (ob j ) ; 

add-informal-functional-requirement-hlec (obj,  kbm) 


method  user-initialize-new-instance  (obj :  remap-position, 

kbm:  kb-module)  = 

edit-hyperstring (obj) ; 

add-inf ormal-functional-requirement-hlec (obj, kbm) 


method  user-initialize-new-instance  (obj:  remap-argument, 

kbm:  kb-module)  = 

edit-hyperstring (obj) ; 

add-informal-functional-requirement-hlec (obj,  kbm) 

method  user-initialize-new-instance  (obj:  remap-assiuiption, 

kbm:  kb-module)  = 

edit-hyperstring (ob j ) ; 

add-informal- functional-requirement -hlec (obj,  kbm) 

method  user-initialize-new-instance  (obj:  remap-constraint, 

kbm:  kb-module)  = 

edit-hyperstring (obj) ; 

add-informal-functional-requirement-hlec (obj,  kbm) 

method  user-initialize-new-instance  (obj:  remap-design-object, 

kbm:  kb-module)  = 

edit-hyperstring (obj) ; 

add-inf ormal-functional-requirement-hlec (obj,  kbm) 


method  user-initialize-new-instance  (obj:  reroap-decision, 

kbm:  kb-module)  = 

edit-hyperstring (obj) ; 

add-informal-functional-requirement-hlec (obj, kbm) 


method  user-initialize-new-instance  (obj:  remap-requirement, 

kbm:  kb-module)  - 

edit-hyperstring (obj) ; 

add- informal- functional-requirement-hlec  (obj,  Icbm) 


%%%%%%%%%%  For  Remap-Position 


var  *remap-position-menu-items* :  any-type  * 

< 

<"Call  Emacs", (lambda  (b,o,p,w) 

excl: :run-shell-comtnand("/usr/local/bin/emacs")  )>, 

<"Show  multi-media", (lambda  (b, o,p,w) 

excl: : run-shell-command (string (format (false, "/usr/openwin/bin/pageview 
/files/isl/remap/figures/~a  4",  (symbol-to-string(name(o) ) )  ))  ))  >, 

<"Show  REMAP  model", (lambda  (b,o,p,w)  excl: : run-shell-command 

("/usr/openwin/bin/pageview  /files/isl/remap/figures/model .ps  &"))>, 
<"Cuckoo", (lambda  (b, o,p,w)  excl: : run-shell-command ("/usr/demo/SOUND/cuckoo. clock" ) ) 


var  *menu-for-remap-positions* :  menu-object  = 
make-menu-object ("Options  for  Position  Node", 

combine-items ( [*sn-objects-menu-items*, *informal-ob jects-menu-items*, 
*remap-position-menu-items*] ) , 

' cd: : semantic-net-window-options) 

method  MOUSE-LEFT-METHOD  (ob j :  cd: : remap-position, p,w)  = 

activate-cd-menu  (*menu-for-remap-positions*, 'mouse-left,  obj,p,  w) 


%%%%%%%%%%%%  For  Remap-requirement 


var  *requirement-menu-items* :  any-type  = 

< 

<"Call  Emacs", (lambda  (b,o,p,w) 

excl: : run-shell-command ("/usr/local/bin/emacs")  )>, 

<"Show  multi-media", (lambda  (b, o,p,w) 

excl: : run-shell-command (string (format (false, "/usr/openwin/bin/pageview 
/files/isl/remap/figures/~a",  (symbol-to-string (name (o) ) )  ))  ))  >, 

<"Show  REMAP  model", (lambda  (b, o,p,w) 

excl : : run-shell-command ( " /usr/openwin/bin/pageview 
/files/isl/remap/figures/model.ps") )>, 

<"Cuckoo",  (lambda  (b,o,p, w)  excl: : run-shell-command ("/usr/demo/SOUND/cuckoo. clock" ) ) 


var  *menu-for-requirements* :  menu-object  = 

IP? ke-menu-object ("Options  for  Requirement  Node", 

combine-items ( [*sn-ob jects-menu-items*, "informal-objects-menu-items*, 
♦requirement -menu-items*] ) , 

' cd: : semantic-net-window-options) 


method  MOUSE-LEFT-METHOD  (obj:  cd: : remap-requirement, p, w)  = 

activate-cd-menu  (*menu-for-requirements*,  'mouse-left,  ob  j,p,  w) 


%%%%%%%%%%  For  Remap-Issue 


var  *reroap-issue-menu- items* :  any-type  = 


<"Call  Emacs",  (launbda  (b, o,p, w) 

excl:  :run-shell-connnand("/usr/local/bin/einacs")  )>, 

<"Show  multi-media",  (lambda  (b,o,p,w) 

excl: : run-shell-command (string (format  (false, ”/usr/openwin/bin/pageview 
/files/isl/remap/figures/~a",  (symbol-to-string (name (o) ) )  ))  ))  >, 

<"Show  REMAP  model", (lambda  (b,o,p,w) 

excl : : run-shell-command ( " /usr/openwin/bin/pageview 
/ f iles/isl /remap/ figures /model. ps") )>, 

<"Cuckoo",  (lambda  (b,o,p,w)  excl: : run-shell-command ("/usr/demo/SOUND/cuckoo. clock" ) ) 


var  *menu-for-remap-issue* :  menu-object  = 
make-menu-object ("Options  for  Issue  Node", 

combine-items ( [*sn-objects-menu-items*, *informal-objects-menu-items*, 
*remap-issue-menu-items*] ) , 

' cd: : semantic-net-window-options) 


method  MOUSE-LEFT-METHOD  (ob j :  cd: : remap-issue, p, w)  = 

activate-cd-menu (*menu-for-remap-issue*, 'mouse-left,  obj,p,  w) 


%%%%%%%%%%  For  Remap-Constraint 


var  *remap-constraint-menu-items* :  any-type  = 

< 

<"Call  Emacs", (lambda  (b,o,p,w) 

excl: : run-shell-command ("/usr/local/bin/emacs")  )>, 

<"Show  multi-media", (lambda  (b, o,p,w) 

excl: : run-shell-command (string (fonnat (false, "/usr/openwin/bin/pageview 
/files/isl/remap/figures/~a",  (symbol-to-string (name (o) ) )  ))  ))  >, 

<"Show  REMAP  model",  (lambda  (b, o,p,w) 

excl : : run-shell-command ( " /usr/openwin/bin/pageview 
/files/isl/remap/figures/model.ps") )>, 

<"Cuckoo",  (lambda  (b,o,p,w)  excl: : run-shell-command ("/usr /demo/SOUND/cuckoo. clock" ) ) 


var  *menu-for-remap-constraint* :  menu-object  = 
make-menu-object ("Options  for  Constraint  Node”, 

combine-items  ( [*sn-objects-menu-items*,  *informal-objects-menu-items*, 
*remap-constraint-menu-items*] ) , 

'  cd: : semantic-net-window-options) 


method  MOUSE-LEFT-METHOD  (ob j :  cd: : remap-constraint, p,w)  = 

activate-cd-menu (*menu-for-remap-constraint*, 'mouse-left,  ob j,p,  w) 


%%%%%%%%%  For  Remap- Argument 


var  *remap-argument -menu-items* :  any-type  = 

< 

<"Call  Emacs", (lambda  (b, o,p,w) 

excl: :run-shell-command("/usr/local/bin/emacs")  )>, 

<"Show  multi-media",  (lambda  (b, o,p,w) 

excl: : run-shell-command  (string (format (false, "/usr/openwin/bin/pageview 
/files/isl/remap/figures/~a",  (symbol-to-string (name (o) ) )  ))  ))  >, 

<"Show  REMAP  model",  (lambda  (b,o,p,w) 

excl : : run-shell-command ( " /usr/openwin/bin/pageview 


/files/isl/remap/figures/model .ps") ) >, 

<"Cuclcoo",  (lambda  (b, o,p,w)  excl: : run-shell-command ("/usr /demo/SOUND/cuckoo. clock." ) ) 
> 


var  *menu-for-remap-argument* :  menu-object  * 
make-menu-object ("Options  for  Argument  Node", 

combine-items ( [*sn-objects-menu-items*, *infonnal-objects-menu-items*, 
* remap-argument -menu-items * ] ) , 

' cd: : semantic-net-window-options) 


method  MOUSE-LEFT-METHOD  (ob j :  cd: : remap-argument, p, w)  = 

activate-cd-menu (*menu-for-remap-argument*, 'mouse-left,  obj,p,w) 


%%%%%%%  For  Assumption 


function  invoke-modify-node-certainty (button:  symbol,  obj:  object, 

pos:  point,  w:  window)  = 

let (new-certainty :  real  =  ri: : single-menu ("Select  Node  Certainty", 

(0.5, 1.0, 1.5, 2. 0,2. 5, 3.0])) 

let  (node-cert:  re::binding  -  cd: : f ind-or-create-attribute 

('node-certainty, ' obj, ' real, diagreun-window-spec-module (w) ) ) 
let (dg-surface:  diagram-surface  =  surface-viewed (w) ) 
let (source-icon:  icon  = 

find-existing-icon-for-spec-ob ject (obj,  dg-surface) ) 
store-attribute (obj, node-cert,  new-certainty) ; 

cd-ui: : icon-color (find-existing-icon-for-spec-ob ject (obj, dg-surface) ) 

<-  cd-ui : : f ind-color-f or-sn-icon (obj ) ; 
cd; ;make-inconsistent-spec-object (obj) ; 
modify-node-certainty-hlec (obj, node-cert, new-certainty) 

var  *assumption-menu-items* :  any-type  = 

< 

<"Add  Assumption  Certainty", ' invoke-add-assumption-certainty>, 

<"Modify  Node  Certainty", ' invoke-modify-node-certainty>, 

<"Call  Emacs", (lambda  (b, o,p,w) 

excl: :run-shell-command("/usr/locai/bin/emacs")  )>, 

<"Show  multi-media", (lambda  (b, o,p, w) 

excl: : run-shell-command (string (format (false, "/usr/openwin/bin/pageview 
/files/isl/remap/figures/~a",  (symbol-to-string (name (o) ) )  ))  ))  >, 

<"Show  REMAP  model", (lambda  (b, o,p, w) 

excl : : run-shell-command (" /usr/openwin/bin/pageview 
/files/isl/remap/figures/model .ps" ) ) >, 

<"Cuckoo", (lambda  (b,o,p, w)  excl: :run-shell-command("/usr/demo/SOUND/cuckoo. clock") ) 
> 


var  *menu-f or-assuitption* :  menu-object  = 

make-menu-object  ("Options  for  Assiuiption  Node", 

combine-items  ( (*sn-objects-menu-iteras*,  *informal-objects-menu-items*, 
*assuit53tion-menu-items*]  > , 

'  cd: : semantic-net-window-options) 


method  MOUSE-LEFT-METHOD  (oh  ):  cd:  :remap-assun5>tion,p, w)  = 

activate-cd-menu (*menu-for-assunption*, 'mouse-left,  obj,p,  w) 


%%%%%%%  For  Remap-Decision 


var  *decision-menu-items* :  any-type  = 


<"Call  Emacs", (lambda  (b,o,p,w) 

excl: :run-shell-command("/usr/local/bin/emacs")  )>, 

<"Show  multi-media", (lambda  (b,o,p,w) 

excl: : run-shell-command (string (format (false, "/usr/openwin/bin/pageview 
/files/isl/remap/figures/~a",  (symbol-to-string (name (o) ) )  ))  ))  >, 

<"Show  REMAP  model", (lambda  (b, o,p,w) 

excl : : run-shell-command ( " /usr/openwin/bin/pageview 
/files/isl/remap/figures/model.ps") )>, 

<"Cuckoo",  (lambda  (b,o,p,w)  excl: : run-shell-command ("/usr/demo/SOUND/cuckoo. clock" ) ) 


var  *menu-for-decision* :  menu-object  = 

raake-menu-object ("Options  for  Decision  Node", 

combine- items ( [*sn-objects-menu-items*, *informal-objects-menu-items*, 
*decision-menu-items*l ) , 

'  cd: : semantic-net-window-options) 


method  MOUSE-LEFT-METHOD  (ob j :  cd: : remap-decision, p,w)  = 
activate-cd-menu (*menu-for-decision*, 'mouse-left, obj,p,  w) 


%%%%%%%%%  For  Remap-Design-Object 


var  *remap-design-ob ject -menu- items* :  any-type  = 

< 

<"Call  Emacs", (lambda  (b,o,p,w) 

excl: : run-shell-command ("/usr/local/bin/emacs")  )>, 

<"Show  multi-media", (lambda  (b, o,p, w) 

excl: : run-shell-command (string (format (false, "/usr/openwin/bin/pageview 
/files/isl/remap/figures/~a",  (symbol-to-string (name (o) ) )  ))  ))  >, 

<"Show  REMAP  model", (lambda  (b,o,p,w) 

excl : : run-shell-command ( " /usr/openwin/bin/pageview 
/ files /isl /remap /figures /model. ps") )>, 

<"Cuckoo", (lambda  (b, o,p,w)  excl: : run-shell-command (" /usr/demo/SOUND/cuckoo. clock" ) ) 


var  *menu-for-remap-design-ob ject* :  menu-object  = 
make-menu-object ("Options  for  Design  Object  Node", 

combine-items ( [*sn-objects-menu-items*, *informal-objects-menu-items*, 
*reinap-design-ob  ject -menu-items*] ) , 

' cd: : semantic-net-window-options) 


method  MOUSE-LEFT-METHOD  (ob j :  cd: : remap-design-object, p,w)  = 

activate-cd-menu (*menu-for-remap-design-ob ject*, ' mouse-left,  ob j,p,  w) 


function  invoke-add-attribute-certainty (button:  symbol,  obj:  object, 

pos:  point,  w:  window)  = 

let (new-certainty :  integer  =  ri: :single-menu(”Select  Certainty", 

[0,1, 2, 3, 4, 5,6,7, 8,  9,10])) 

let (ai-target :  re::universe  =  attribute-instance-target (obj) , 

ai-attribute:  re::binding  =  attribute- instance-attribute (obj) , 
dg-surface:  diagram-surface  =  surface-viewed (w) ) 
let  (source-icon:  icon  = 

find-existing-icon-for-spec-object (ai-target, dg-surface) ) 
cd: : store-attribute-facet (ai-target, ai-attribute, 

' cd: : certainty, new-certainty) ; 


erase-object (obj) ; 
update-sn-icon (source-icon, w) 


function  invoice-retrieve-certainty (button:  symbol,  obj:  object, 

pos:  point,  w:  window)  « 

cd: : retrieve-attribute- facet (attribute-instance-target (obj) , 
attribute-instance-attribute (obj) , ' cd: : certainty) 


var  *sn-objects-menu-iteins* :  any-type  » 

< 

<"Modify  Certainty", ' invoke-add-attribute-certainty, ' sn-graph?>, 
<"Retrieve  Certainty", ' invoke-retrieve-certainty, '  sn-graph?>, 

<"Add  Link" , ' add-sn-link, ' an-graph?>, 

<"Create  Possible  Resolutions", ' invoke-make-possible-resolutions, 

' issue?>, 

<"Show  Links  in  Current  View", ' show-sn-links-and-refresh, '  sn-graph?>, 
<"Show  Selected  Links", ' show-selected-links-and-refresh, '  sn-graph?> 

> 


var  *menu-for-slots* :  menu-object  - 

make-menu-object ("Options  for  Slots", *sn-objects-menu-items*, 
' cd: :options-for-classes) 


method  mouse-left-method  (obj:  ri: :icon,pos:  point,  w:  window)  = 
if  agl-link-label? (ob j) 

then  mouse-left-method (spec-object-for-link (agl-link-for-label (ob j ) ) , 

pos, w) 

else  mouse-left-method (spec-object-for-icon (ob] ), pos,  w) 


method  mouse-left-method  (obj:  attribute-instance, pos:  point,  w:  window) 
activate-cd-menu ("menu- for-s lots*, 'mouse-left, obj, pos, w) 
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!!  in-package ("CD") 
!  !  in-grararoar ( ' gr ) 


function  modify-node-certainty (obj : object,  node-cert:  re::binding,  new-certainty : 

cd:  :inake-inconsistent-spec-ob ject  (obj) ; 
cd: :make-inconsistent-spec-object (node-cert) 


!!  in-grammar ('hlec-grammar) 

hlec  modify-node-certainty-tenplate 

context-name-pattern ["Changed  the  value  of","0") 

context -description-pattern ["Set  the  value  of", "2", "on",  "0",  "to",  "3"] 


!  !  in-grammar ( ' user ) 

form  gen-hlecs 
generate-hlecs  () 


real) 
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!  !  in-package ( " CD-UI " ) 
1 !  in-grammar ( ' gr ) 


%%  This  file  is  primarily  a  duplicate  of  the  original 
%%  Concept  Demop  work  with  minor  changes  to  incorporate 
%%  the  REMAP  inplementation. 

var  *viewable-slots-for-diagram-windows*  :  set (re; : binding)  • 
( f ind-attribute-or-complain (' cd-ui : :max-tree-depth) , 
find-attribute-or-complain (' cd-ui: :tree-depth-spacing) , 
find-attribute-or-complain (' cd-ui: : tree-breadth-spacing) , 
f ind-attribute-or-complain (' cd-ui : : tree-graph-direct ion) 

} 


var  *default-viewable-slots* :  set (re: : binding)  - 
(find-attribute-or-con5)lain(' cd: : class) , 
f ind-attribute-or-conplain (' attached-notes) 

%%f  ind-attribute-or-coirplain  ('  agenda-items) 

} 

union 

( find-attribute-or-conplain (' created-by) , 
f ind-attribute-or-conplain (' last-modified-by) , 
find-attribute-or-con5)lain(' cd: :created-on-date) , 
find-attribute-or-conplain (' cd: : last-modi fied-on-date) } 

var  *viewable-slots-for-kb-module-objects* :  set (re: : binding)  = 

( f ind-attribute-or-conplain (' owned-by) , 
f  ind-attribute-or-coiT?}lain  ('  created-by) , 
f ind-attribute-or-conplain (' last-modified-by) , 
f  ind-attribute-or-con?)lain  ('  formalizes) , 
find-attribute-or-con?)lain  ('  inplements) , 
find-attribute-or-con?)lain (' unresolved-issues) } 
union  f ind-attributes-or-complain ( { ' created-by-task, ' deleted-by-task, 

'modified-by-tasks) ) 


union 

{ find-attribute-or-con^jlain (' cd: :created-on-date) , 
find-attribute-or-con^Jlain (' cd: :last-modified-on-date) } 

var  *viewable-slots-for-modules* :  set (re: : binding)  = 
♦default-viewable-slots*  union 
{ f ind-attribute-or-conplain (' ownert-objects) , 
f ind-attribute-or-con^jlain (' uses-kb-modules) , 
f ind-attribute-or-con?)lain (' exported-ob ject-names) , 
find-attribute-or-conqplain (' exported-ob jects) , 
find-attribute-or-conplain  ('  )tb-module-version) , 
f ind-attribute-or-conplain (' development -history) 

) 

var  *viewable-slots-for-sms* :  set (re: :binding)  = 

*default-viewable-slots*  union  *vieweUole-slots-for-modules*  union 
{ find-attribute-or-con^ilain (' requirement -modules) , 
f ind-attribute-or-conplain (' test-modules) , 
find-attribute-or-coirplain ('used-by-Jcb-modules) } 

var  *viewable-slots-for-tms* :  set (re: :binding)  = 

♦default-viewable-slots*  union  *viewable-slots-for-modules*  union 
( f ind-attribute-or-complain (' test-module-of) } 

var  *viewable-slots-for-rms* :  set (re: : binding)  = 

♦default-viewable-slots*  union  *viewable-slots-for-modules*  union 
( find-attribute-or-coitplain  ('  inplementation-modules) } 

var  *viewable-slots-for-relations* :  set (re: : binding)  = 

♦de  f ault-viewable-s lot s  * 


union  *viewable-slots-for-kb-module-objects*  union 
{ find-attribute-or-complain (' relation-range) , 
find-attribute-or-coinplain  ('  relation-domain) , 
find-attribute-or-coir5>lain  ('  range-cardinality) , 
find-attribute-or-conplain (' domain-cardinality) , 
f ind-attribute-or-complain (' used-by) , 
find-attribute-or-complain {' certainty) , 
f ind-attribute-or-con^jlain (' modif ied-by) } 

var  *viewable-slots-for-er-atts* :  set (re: :binding)  = 
*default-viewable-slots* 

union  *viewable-slots-for-kb-module-objects*  union 
( f ind-attribute-or-complain (' used-by) , 
find-attribute-or-conplain ('modified-by) ) 


var  cd-ui : : *viewable-slots-for-hypertext*  :  set (re: :binding)  = 
(find-attribute-or-complain (' formalized-by) , 
f ind-attribute-or-complain (' inqplemented-by) , 
f ind-attribute-or-complain (' responds-to) , 
find-attribute-or-con^lain (' supports) , 
find-attribute-or-complain (' objects-to) , 
f  ind-attribute-or-corr^ilain  ('  questions) , 
find-attribute-or-coit^jlain  ('  replaces) , 
f ind-attribute-or-complain ('  generalizes) , 
find-attribute-or-conplain (' specializes) , 
f ind-attribute-or-con^lain (' is-suggested-by) , 
find-attribute-or-complain (' substitutes-f or) , 
find-attribute-or-complain (' substituted-for-by) , 
find-attribute-or-con^jlain  ('  suggests) , 
f ind-attribute-or-complain ('  defines) , 
f ind-attribute-or-conplain ('qualifies) , 
find-attribute-or-conplain (' triggers) , 
find-attribute-or-conplain  ('  exen5)lifies) , 
find-attribute-or-corqalain ('precedes) , 
find-attribute-or-conplain (' follows) , 
find-attribute-or-con^Jlain (' requires-input) , 
find-attribute-or-complain ('produces-output) , 
f ind-attribute-or-conplain ('done-using) , 
find-attribute-or-conplain (' check-f or- interact ion) , 
find-attribute-or-con^jlain (' check-f or-redundancy) , 
find-attribute-or-con^jlain (' check-f or-conflict) , 
find-attribute-or-con^jlain (' resolve-contradiction) , 
find-attribute-or-complain (' describes-inconpleteness-of) , 
find-attribute-or-conplain ('describes-incorrectness-of ) , 
find-attribute-or-conplain (' describes-general-inadequacy-of ) , 
find-attribute-or-conplain (' see-also) , 
find-attribute-or-coirqplain  ('unresolved-issues) , 
find-attribute-or-con^jlain ('describes-issue-for) , 
find-attribute-or-corqjlain (' described-issue-for) , 
find-attribute-or-complain (' resolved-by) , 
find-attribute-or-conplain ('possible-resolutions) , 

%%%%  REMAP  specific  attributes  are  adder  here. 

f ind-attribute-or-conqplain (' node-certainty) , 
find-attribute-or-conplain  ('assuitption-certainty) , 
f ind-attribute-or-conplain (' decision-modifies-requirement) , 
find-attribute-or-con5)lain  ('  recjuirement-generalizes-requirement) , 
f ind-attribute-or-con^jlain (' requirement-specializes-requirement) , 
find-attribute-or-coirplain  ('  requirement-generates-issue) , 
f ind-attribute-or-conplain (' requirement-leads-to-decision) , 
f ind-attribute-or-conplain (' issue-generalizes-issue) , 
f  ind-attribute-or-coirplain  ('  issue-specializes-issue) , 
f ind-attribute-or-conplain (' issue-replaces-issue) , 
find-attribute-or-complain (' issue-questions-issue) , 


find-attribute-or-conplain(' issue-suggested-by-issue) , 
find-attribute-or-coniplain (' issue-suggested-by-position) , 
£ind-attribute-or-con9>lain (' issue-suggested-by-argument) , 
find-attribute-or-complain ('position-responds-to-issue) , 
find-attribute-or-coinplain  ('  argvunent-supports-position) , 
find-attribute-or-conplain (' argument-ob jects-to-position) , 
£ind-attribute-or-conqplain  ('  argxunent-depends-on-assunption) , 
find-attribute-or-conplain  ('  assuirption-qualifies-argument) , 
find-attribute-or-conplain ('decision-resolves-issue) , 
f ind-attribute-or-complaxn (' decision-selects-position) , 
f ind-attribute-or-con5>lain (' decision-generalizes-decision) , 
find-attribute-or-coinplain (' decision-specializes-decision) , 
f ind-attribute-or-conplain (' decision-depends-on-decision) , 
find-attribute-or-conplain ('decision-inplies-constraint) , 
find-attribute-or-conplain ('decision-leads-to-constraint) , 
find-attribute-or-conplain (' deciaion-generates-constraint) , 
find-attribute-or-con?>lain (' constraint -creates-design-object) , 
find-attribute-or-complain (' conatraint-removes-design-object) , 
find-attribute-or-conplain (' conatraint-modifies-design-object) , 
find-attribute-or-coirplain (' design-object -depends-on-constraint) 


var  *viewable-3lots-for-hypernodes* :  set (re: :binding)  - 
♦default-vxewable-slots* 

union  *viewable-slots-for-)cb-module-objects* 

union  f ind-attributes-or-con^ilain ( ( ' sub-nodes, ' super-node } ) 

union  *viewable-slots-for-hypertext* 

var  *viewable-slots-for-explanations*  : set (re: : binding)  « 
f ind-attributes-or-con^lain ( { ' object -explained} )  union 
*viewable-slots-for-hypernodes* 


var  *viewable-slots-for-hypertext-requirements* :  set (re: : binding)  ■ 
♦default- viewable-slots* 
union  *viewable-slots-for-hypernodes* 
union  *viewable-slots-for-hypertext* 

var  *viewcd5le-slots-for-notes* :  set (re: :binding)  - 
♦default-viewable-slots* 

union  *viewable-slots-for-kb-moduie-objects* 
union  { f ind-attribute-or-conplain (' attached-to) } 

var  *viewaJDle-slots-for-agenda-items* :  set (re: : binding)  - 
♦default-viewable-slots* 

union  *viewable-slots-for-)tb-module-object5* 

%% { f ind-attribute-or-conplain (' spec-ob jects-for-agenda-item) } 

%%  ViewedJle  slots  for  each  REMAP  node  that  only  includes 

%%  the  appropriate  linlcs  for  that  node. 

var  *viewable-slots-for-remap-requirement- :  set (re: : binding)  - 
( f ind-attribute-or-complain (' requirement-leads-to-decision) , 
find-attribute-or-conplain (' requirement-generates-issue) , 
find-attribute-or-conplain (' requirement -generalizes-requirement) , 
find-attribute-or-complain (' requirement-specializes-requirement) } 

var  *viewable-slots-for-remap-issue*;  set (re: :binding)  - 
( f ind-attribute-or-complain (' issue-generalizes-issue) , 
find-attribute-or-conplain (' issue-specializes-issue) , 
f ind-attribute-or-complain (' issue-replaces-issue) , 
f ind-attribute-or-conplain (' issue-questions-issue) , 
f ind-attribute-or-conplain (' issue-suggested-by-issue) , 
find-attribute-or-complain (' issue-suggested-by-arg\ament) , 
f ind-attribute-or-conplain (' issue-suggested-by-position) } 


var  *viewable-slots-for-reinap-position* :  set (re :: binding)  = 
(find-attribute-or-conplain('positiO-  -responds-to-issue) } 

var  ‘viewable-slots-for-remap-argument* :  set (re: :binding)  = 

( find-attribute-or-complain (' arcniment-supports-position) , 
find-attribute-or-coit53lain  ('  argument-ob jects-to-position)  , 
f ind-attribute-or-complain  ('  argument -depends-on-ass\ur5)tion) } 

var  *viewable-slots-for-remap-assumption* :  set (re: : binding)  = 
(find-attribute-or-coir^jlain  ('  assunption-qualifies-argument)  } 

var  *viewable-3lots-for-remap-decision* :  set (re : :binding)  - 

(find-attribute-or-conqplain (' decision-modifres-requirement) , 
f ind-attribute-or-conplain (' decision-generalizes-decision) , 
find-attribute-or-complain (' decision-specializes-decision) , 
find-attribute-or-complain  ('  deci.*=ion-depends-on-decision) , 
find-attribute-or-complain (' decision- in^jlies-constraint) , 
f ind-attribute-or-conplain (' decision-leads-to-constraint) , 
find-attribute-or-conplain (' decision-generates-constraint) , 
find-attribute-or-conplain ('decision-resolves-issue) } 

var  *viewable-slots-for-remap-constraint* :  set (re: : binding)  = 

( f ind-attribute-or-conplain ( ' constraint-creates-design-ob ject ) , 
find-attrihute-or-conplain (' constraint-removes-design-object) , 
find-attribute-or-complain (' constraint -modifies-design-ob ject) ) 

var  *viewable-slots-for-remap-design-ob ject* :  set (re: : binding)  = 

{ find-attribute-or-conplain ('design-object -depends-on-constraint) } 


var  *viewabls-slots-for-invariant-violations* :  set (re: : binding)  = 

{ f  iiid-attribute-or-complain  ('  violation-objects) , 
find-attribute-or-complain (' violated-invariant) }  union 
*default-viewable-slots*  union  *viewable-slots-for-)cb-module-ob jects* 

var  *viewable-slots-for-invariants* :  set (re: : binding)  = 

{ find-attribute-or-complain ( ' maintained-by ) }  union 

*default-viewable-slots*  union  *viewable-slots-for-)cb-module-ob jects* 

var  *viewable-slots-for-demons* :  set (re: : binding)  = 
(find-attribute-or-complain ('maintains) )  union 

*default-viewable-slots*  union  *viewable-slots-for-)cb-module-ob jects* 

var  *viewable-slots-for-people* :  set (re: : binding)  = 
*default-viewable-slots* 

union  *viewable-slots-for-)cb-module-ob jects* 
union  { find-attribute-or-corrplain  ('home-directory) , 

f ind-attribute-or-conplain (' cd-user-directory) , 
find-attribute-or-complain (' cd: :assigned-to-task5) , 
find-attribute-or-conplain (' on-critical-path?) , 
find-attribute-or-con^Jlain ('percent-committed) 

} 

var  *viewable-slots-for-staff * :  set (re: :binding)  = 
*viewable-slots-for-people* 
union 

find-pma-attributes ( { ' pma : : PERCENTAGE-AVAILABILITY, ' pma : : cost-per-day, 
'pma: : skills}) 

function  viewable-slots-for-run-time-instance  (o:  object)  “ 

(a  I  (a)  a  in  class-attributes (instance-of (o) ,  true)  & 
defined? (owned-by(a) ) }  union  { find-attribute-or-conplain (' cd: : class) } 

var  *viewable-slots-for-pma-task-plans* :  set (re: ; binding)  = 


♦default-viewable-slots*  union 
(if  cd: : *pma-loaded?* 
then 

find-pma-attributes(('pina: : task-type, 'pma: :8cheduled-start, 

'pma: :earliest-start, 

'pma: : latest-start, 

' pma : : scheduled-f inish, 

'pma: :earliest-f inish, 

' pma : : latest-finish, 

'pma: :personnel-commitments}) 
else  {}) 

var  *viewable-slots-for-cd-tasks* :  set (re: :bindlng)  - 

f ind-attributes-or-coirplain  ( ( '  ob jects-created,  '  ob jects-modif ied, 

' resolves, ' cd: : consisted?, 

' sub-tasks, ' cd: ; issue-to-resolve, 

' cd: :assigned-to, ' critical-path-task?, 

'  estiinated-person-hours, '  milestone?, 

' in-violation-of-policies, 

' scheduled-completion-date} ) 
union  *viewable-slots-for-pma-task-plans* 
union  *viewable-slots-for-hypernodes* 

var  *non-functional-req-slots-for-classes* :  set (re: :binding)  -■ 
find-attributes-or-complain ({'maximum-number-of-instances, 

'  minimum-number-of-instances,  ' average-nurober-of-instances, 

'  maximiun-creation-frequency,  ' average-creation-frequcncy ) ) 

var  *non-functional-req-slots-for-functions* :  set (re: :binding)  - 

find-attributes-or-complain  ( { '  occurance-f requency, '  minimum-processing-tiroe, 
'  required-reliability, ' required-fault-tolerance, ' required-survivability  >) 

var  *viewable-slots-for-functions*:  set (re: :binding)  - 
*default-viewable-slots* 

union  •viawable-slots-for-kb-module-objects*  union 
find-attributes-or-complain (('uses, 'modifies, 'used-by})  union 
*non-functional-req-slots-for-£unctions* 

var  *viewable-slots-for-classes* :  set (re: :binding)  - 
•non-functional-req-slots-for-classes* 
union  *default-viewable-slots*  union 
*viewable-slots-for-kb-module-obJects* 


REMAP  viewable  slots. 

var  viewable-slots:  map (re :: universe,  set (re: :binding) ) 
computed-using 

remap-requirement (x)  ->  viewable-slots (x)  - 
*viewable-slots-£or-remap-requirement*, 
remap-issue (x)  ->  viewable-slots (x)  - 
* viewable-slot s-for-remap-issue*, 
remap-position (x)  ->  viewable-slots (x)  « 
•viewable-slots-for-remap-position*, 
remap-argument (x)  ->  viewable-slots (x)  - 
*viewable-slots-£or-remap-argument*, 
remap-assumption (x)  ->  viewable-slots (x)  - 
♦viewable-slots-for-remap-aasumption*, 
remap-decision (x)  ->  viewable-slots (x)  » 
•viowablo-slots-for-remap-decision*, 
remap-constraint (x)  ->  viewable-slots (x)  • 
♦viewablo-slots-for-remap-constraint*, 
remap-design-object (X)  ->  viewable-slots (x)  • 

* viewable-slot s-for-romop-design-object*. 


object-class? (x)  ->  viewable-slots (x)  = 

*viewable-slots-for-classes*, 
person (x)  *>  viewable-slots (x)  « 

*viewable-slots-f or-people* , 

pma: : staff (x)  ->  viewable-slots (x)  = 

*viewable-slots-for-staf f*, 

Cd-task(x)  ->  viewable-slots (X)  =  *VIEWABLE-SLOTS-FOR-CD-TASKS*, 

re: : invariant-op (x)  =>  viewable-slots (x)  = 

*viewable-slots-for-invariants*, 

re: : demon-op (x)  ->  viewable-slots (x)  - 

*viewcd)le-slots-for-demons*, 

invariant -violation-record (x)  =>  viewable-slots (x)  = 
*viewabls-slots-for-invariant-violations*, 
run-time-instance?  (x)  =>  viewable-slots  (x)  »= 
viewable-slots-for-run-time-instance (x) , 

kb-module(x)  =>  viewable-slots (x)  =  *viewcd>le-slots-for-modules*, 
re: :vfunction-op(x)  =>  viewable-slots (x)  =  ‘viewable-slots-for-functions 
er-attribute? (x)  =>  viewable-slots (x)  =  *viewable-slots-for-er-atts*, 
er-relation? (x)  =>  viewable-slots (x)  =  *viewable-slots-for-relations*, 
%%agenda-item(x)  => 

%%viewable-slots (x)  =  *viewable-slots-for-agenda-items*, 
hypertext-requirement (x)  => 

viewable-slots  (x)  =  *viewable-slots-for-hypertext-requirements*, 
explanation  (x)  =>  viewable-slots (x)  =  *viewable-slots-for-explanations*, 
note(x)  => 

viewable-slots (x)  =  *viewable-slots-for-notes*, 

pma-thing? (x)  =>  viewable-slots (x)  =  viewable-slots-for-pma-ob ject (x) , 
hypertext-node (x)  =>  viewable-slots (x)  =  *viewable-slots-for-hypernodes* 
ri: : diagram-window (x)  =>  viewable-slots (x)  = 

♦viewable-slot s-for-diagram-windows*, 
true  =>  viewable-slots (@@)  = 

♦default-viewable-slots*  union  ♦viewable-slots-for-kb-module-ob jects* 


var  *display-undefined-attributes?* :  boolean  =  false 

function  interesting-value?  (val : any- type)  :boolean  = 
if  cd: : ♦specification-debugging-enabled-p* 
then  defined? (val) 

else  defined? (val)  and  not (null (val) ) 

var  slots-to-hide :  map (re :: universe, set (re : :binding) ) 
conputed-using  slots-to-hide () 

function  find-viewable-slots  (o:object)  :seq(re: :binding)  = 
let (possible-attributes  =  setdiff (viewable-slots (o) , 

slots-to-hide (instance-of (o) ) ) ) 

if  ♦display-undefined-attributes?* 
then  sort-objects (possible-attributes) 
else 

sort-objects (filter (lambda  (a)  interesting-attribute? (o, a) , 
possible-attributes) ) 


var  ♦default-hypertext-slots*:  set (re: : binding)  = 

( find-attribute-or-complain ('hypertext-string) ) 

var  ♦all-hypertext-slots*:  set (re : :binding)  = 
♦default-hypertext-slots* 

var  ♦default-max-depth*:  integer  =  50 

var  max-tree-depth:  map (diagram-window,  integer) 

conputed-using  max-tree-depth (@@)  =  ♦default-max-depth* 
var  tree-depth-spacing:  map (diagram-window,  real) 
conputed-using  tree-depth-spacing (@@)  =  1.8 


var  tree-breadth-spacing;  map (diagram-window,  real) 
con5>uted-using  tree-breadth-spacing (00)  •  1.0 
var  tree-graph-direction:  map (diagram-window,  symbol) 
conputed-using  tree-graph-direction (00)  -  'right 

form  go-form 

cache ('max-tree-depth, true) ; 
cache ('tree-depth-spacing, true) ; 
cache ('tree-breadth-spacing, true)  ; 
cache ('  tree-graph-direction, true) 


!  !  in-pac)cage  ('  cd) 

function  find-atts-to-copy  (obj-class:  object)  : set (re: : binding)  - 
let (atts-to-copy  - 

class-attributes (obj-class,  true)  less  find-attribute (' name) ) 
atts-to-copy  <- 

filter (lambda (att)  symbol-package (name (att ) )  ~»=  find-package ("CD-UI") 
atts-to-copy) ; 

%%atts-to-copy  <-  filter (lambda (att)  enpty (re: :using-assertions (att) ) 
%%  atts-to-copy) ; 

atts-to-copy  <-  setdif f (atts-to-copy, 

f ind-attributes-or-con5)lain ( { ' created-by-task, ' deleted-by-task, 
'modified-by-tasks, ' created-on-date, ' last-modified-on-date, 

'  created-by, '  last-modified-by,  'pma: : vers ion-name } ) )  ; 
atts-to-copy 
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!!  in-package ("CD") 
!!  in-granimar  (' user) 


%%%%%%%%%  Latest  version  of  facets. re  that  allows  attributes  of 
%%%%%%%%%  attributes,  and  adds  attribute-instance  object 

function  attribute-facet-name  (attr:  re: : binding, facet-name:  symbol) 

: symbol  = 

let (facet-package:  any-type  =  symbol-package (facet-name) , 

facet-name-string:  string  -  string-upcase (format (false, "~a — a", 

name (attr) ,  facet-name) ) ) 

intern (facet -name-string, facet-package) 


function  find-attribute-facet  (attr:  re :: binding, facet-name :  symbol)  = 
find-attribute (attribute-facet-name (attr, facet-name) ) 

function  find-or-create-attribute-facet  (attr:  re:: binding, 

facet-name:  symbol)  = 

let (existing- facet :  re::binding  =  find-attribute-facet (attr,  facet-name) ) 
if  defined? (existing-facet) 
then  existing-facet 

else  create-attribute-facet (attr, facet -name) 

function  create-attribute-facet  (attr:  re: :binding, facet-name:  symbol)  = 
let (facet-domain-class :  re::binding  =  find-relation-domain-class (attr) , 
attribute- facet-name :  symool  =  attribute-facet-name (attr,  facet-name) ) 
display-debug-message (format (false, 

"~%Generating  new  attribute  to  serve  as  facet:  ~a~%", attribute-facet-name) ) 
make-attribute (attribute-facet-name, name  (facet-domain-class) , 

'any-type' , true) 


function  retrieve-attribute-facet  (target:  re: : universe, attr :  re::binding, 

facet-name:  symbol)  = 

let (attribute-facet:  re: :binding  =  find-attribute- facet (attr,  facet-name) ) 
if  defined? (attribute-facet) 

then  retrieve-attribute (target, attribute-facet) 
else  display-debug-message (format (false, 

"~%Warning!  Tried  to  retrieve  undefined  facet:  ~a  from  ~a", 

facet-name,  name (attr) ) ) ; 

undefined 


function  store-attribute-facet  (target:  re: :universe,attr:  re::binding, 

facet-name:  symbol,  new-value:  any-type)  = 
let (attribute- facet :  re:: binding  = 

find-or-create-attribute-facet (attr, facet-name) ) 
store-attribute (target, attribute-facet, new-value) 


%%%%%%  Defining  a  new  class  "attribute-instance”  to  stand  for 
%%%%%%  the  particular  value  of  an  attribute  on  a  class 


var  attribute-instance:  object-class  subtype-of  user-object 

var  attribute-instance-target:  map (attribute-instance,  re : :universe)  =  {||} 

var  attribute-instance-attribute:  map (attribute-instance,  re: :binding)  =  {||} 

function  find-or-create-attribute-instance  (instance-target:  re : :universe, 

instance-attribute:  re::binding) 

:  attribute-instance  •= 

let (exist ing-attribut e-instance:  attribute-instance  = 

find-attribute-instance (instance-target, instance-attribute) ) 
if  defined? (existing-attribute-instance) 
then  existing-attribute-instance 


else  create-attribute-instance (instance-target, instance-attribute) 


function  find-attribute-instance  (instance-target:  re: runiverse, 

instance-attribute:  re: : binding) 

:  attribute-instance  •= 

let (all-attribute-instances:  set (attribute-instance)  = 

instances (find-object-class ('attribute-instance) ,  true) ) 
let (existing-attribute-instance:  attribute-instance  = 
some(x)(x  in  all-attribute-instances  & 

attribute-instance-target (x)  -  instance-target  & 
attribute-instance-attribute (x)  »  instance-attribute)) 
existing-attribute-instance 

function  create-attribute-instance  (instance-target:  re: :universe, 

instance-attribute:  re::binding) 

:  attribute-instance  « 

let (new-attribute-instance:  attribute-instance  = 
make-object ('attribute-instance) ) 

attribute-instance-target (new-attribute-instance)  <-  instance-target; 
attribute-instance-attribute (new-attribute-instance)  <-  instance-attribute 
new-attribute-instance 

form  export-attribute-instance-info 

export ( ('  cd: : find-or-create-attribute-instance, ' cd: : attribute-instance, 

'  cd: : attribute-instance-target, ' cd: : attribute-instance-attribute, 
'cd: : store-attribute-facet,  'cd: : retrieve-attribute- facet, 

'cd: : find-attribute-instance}, 

'cd) 
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!!  in-package ("CD-UI") 
! !  in-grairanar  ('user) 


function  graph-ibis-model  (objs:  set (re: runiverse) ,  title-string:  string)  = 
graph-basic-sn-model (objs, 

f ind-attributes-or-complain ( ( ' responds-to, ' supports, ' ob jects-to, 

'  questions, '  replaces, '  generalizes, 

' specializes, ' is-suggested-by} ) , 
title-string) 


function  graph- ibis-model-for-module  ()cbm:  kb-module)  = 

let (ibis-nodes :  set (ibis-node)  =  {x| (x)  x  in  owned-ob jects (kbm) 

&  ibis-node (x) } ) 

graph-ibis-model (ibis-nodes, 

format (false, "IBIS  Model  for  KB-module:  ~a", 
name (kbm) ) ) 


function  contains-ibis-nodes?  (button:  symbol,  kbm:  object, 
pos:  point,  w;  window)  -.boolean  = 
ex(x) (X  in  owned-ob jects (kbm)  &  ibis-node (x) ) 


function  invoke-graph-ibis-model-for-module  (button:  symbol,  thing:  object, 
pos:  point,  w:  window)  =  graph- ibis-model-for-module (thing) 


%%  Incorporated  to  work  with  attribute  facets. 


function  show-sn-linkage  (att:  object,  obj:  object,  att-value:  any-type, 

dw : diagram-window, only-if-visible? :  boolean)  = 

(if  listp (att-value) 
then 

(if  length (att-value)  >  3  &  ~only-if-visible?  then 
(display-message ( 

format (false, "~a  has  -a  values. ~%Do  you  really  want  to  graph  them?", 
name  (att) , length (att-value) ) ) ; 

(if  yes-or-no-menu ("Graph  Them?")  then 

(enumerate  v  over  att-value  do  show-sn-linkage (att,  obj,v,  dw, 

only-if-visible?) ) ) ) 

else  (enumerate  v  over  att-value  do  show-sn-linkage (att,  obj,v,  dw, 

only-if-visible?) ) ) 

else 

let (existing-ai:  attribute- instance  = 
find-attribute-instance (obj, att) ) 
let (existing-link :  link  = 
if  defined? (existing-ai) 

then  find-2-way-link (existing-ai,  obj,  att-value, dw) 
else  undefined) 

(if  defined? (existing-link) 
then  existing-link 

else  create-sn-link (att,  obj,  att-value, dw) ) ) 


function  make-link-for-sn-object  (att:  re::binding, 

obj:  object,  s : diagram-surface) 

:  ri : :drawable-object  = 

let  (attribute-instance- object .  attriIL/ute-i,i3tance  = 
find-or-create-attribute-instance (obj,  att) ) 
let (dw:  diagram-window  =  arb (viewports (s) ) ) 
let  (new-link  = 

if  ag 1-window? (dw) 

then  make-default-agl-link 0 


else  default-make-link (dw) ) 
set-link-laUsel  (new-link, 

make-sn-label-for-certainty (attribute-instance-object) ) ; 
links-for-spec-ob ject (attribute-instance-object)  <- 
links-for-spec-object (attribute-instance-object)  with  new-link; 
set-link-surface (new-link, s) ; 
new-link 


function  make-sn-laUDel-for-certainty  (ai:  attribute-instance):  seq(string) 

let (ai-target :  re::universe  -  attribute-instance-target (ai) , 

ai-attribute:  re::binding  =  attribute-instance-attribute (ai) ) 
let (ai-certainty :  any-type  - 

cd:  : retrieve-attribute-facet (ai-target, ai-attribute,  'cd: : certainty) ) 
(if  undefined? (ai-certainty)  then  ai-certainty  <-  1); 
make-label (format (false, "-a:  -a",  name  (ai-attribute) ,  ai-certainty)) 


function  create-sn-link  (att:  object,  obj:  object,  att-value: object, 

dw: diagram-window)  « 
with-screen-updates-disabled (dw, 
let (surf:  diagram-surface  =  sur face-viewed (dw) ) 
let (source-icon:  icon  *>  find-or-create-sn-icon (obj,  surf, true) , 

target-icon:  icon  =  find-or-create-sn-icon (att-value,  surf ,  true) , 
sn-link:  link  «  make-link-for-sn-ob ject (att, obj, surf ) ) 

(if  ~agl-window? (dw)  then 
dynamic? (sn-link)  <-  true); 
set-cd-target-arrow (sn-link,  true) ; 
set-cd-source (sn-link, source-icon)  ; 
set-cd-target (sn-link, target-icon) ; 

(if  agl-window? (dw)  then 
create-arced-link (sn-link,  dw) ) ) ; 
refresh-window (dw) 


function  Make-Label-for-sn-icon  (tn:  object):  seq(string) 

«s 

let (obj-class :  re::binding  =  instance-of (tn) ) 
make-label (format (false,  "~a:  ~a",  name  (obj-class) , 

obj-name (tn) ) ) 

%%  IBIS  nodes  are  boxes,  assurtptions  are  diamonds,  others  are  rectangles. 

function  f ind-shape-for-sn-icon  (obj:  object)  :symbol  = 
if  remap-position (obj)  then  'ri::box 
elseif  reinap-issue  (obj)  then  'ri::box 
elseif  remap-argument (obj)  then  'ri::box 
elseif  remap-assunption (obj)  then  'ri::diamond 
else  'ri:: ellipse 

function  find-color-for-sn-icon  (obj:  object)  :symbol  » 
let (cert:  real  =  node-certainty (obj) ) 
if  remap-position (obj)  then  cw::magenta 
elseif  remap-argument (obj)  then  cw: :turquoise 
elseif  remap- is sue (obj)  then  cw::blue 
elseif  remap-requirement (obj)  then  cw: : black 
elseif  remap-decision (obj)  then  cw::magenta 
elseif  remap-constraint (obj)  then  cw: : turquoise 
elseif  remap-design-object (obj)  then  cw::blue 
elseif  remap-assxonption (obj)  then 

if  cert  <=  1.0  then  cw::red 

elseif  cert  >  1.0  and  cert  <=•  2.0  then  yellow 
else  cw:: green 
else  cw: : white 


function  make-icon-for-sn-object  (f:  object, surf:  diagram-surface)  :icon  * 
let  (new-icon  -  make-object (' icon) ) 
size-factor (new-icon)  <-  1.0; 
height -width-ratio (new-icon)  <-  .7; 
icon-type (new-icon)  <-  find-shape-for-sn-icon(f) ; 
label (new-icon)  <-  Make-Label-for-sn-icon (f)  ; 
icon-color (new-icon)  <-  f ind-color-for-sn-icon (f ) ; 
icons-for-spec-object (f )  <- 
icons-for-spec-object (f )  with  new-icon; 
home-surface (new-icon)  <-  surf; 
new-icon 


function  graph-basic-sn-model(  el-objs:  set (object),  rel-atts:  set (object), 
title:  string)  » 

let  (dw:  diagreim-window  -  make-ob  ject  (' diagram-window) , 

surf:  diagram-surface  =  make-object ('diagram-surface) 

) 

(if  *use-color*  then 

do-color (native-window (dw) , cda: :turquoise,  cda: :black) )  ; 
presentation-type (dw)  <-  ' sn-graph; 
add-colored-icons-to-window (dw) ; 
sn-window-related-attributes (surf )  <-  rel-atts; 
diagram-window-spec-module (dw)  <-  owned-by (arb (sel-ob js) )  ; 
with-screen-updates-disabled (dw, 

(window-title (dw)  <-  title; 

window-region (dw)  <-  default-output-region () ; 
surface-viewed (dw)  <-  surf; 

mouse-handler (dw)  <-  ' sn-diagram-mouse-handler; 
window-mouse-handler (dw)  <-  ' bring-f orward; 
setup-agl-window(dw)  ; 
agl-window? (dw)  <-  *use-agl?*; 
make-sn-icons (sel-ob js, rel-atts,  surf) ) ; 
show-all-links-in-view(dw, surf) ) ; 
view-surface (dw,  surf)  ; 
expose-window (dw) 


function  graph-remap-model  (objs:  set (re: :universe) ,  title-string:  string)  = 
graph-basic-sn-model (objs, 

f ind-attributes-or-complain ( ( ' decision-modif ies-rec[uirement, 

' assumption-certainty, 

' node-certainty, 

'  requirement -generalizes-requirement, 

'  requirement-specializes-requirement, 

'  requirement-generates-issue, 

'  requirement-leads-to-decision, 

' issue-generalizes-issue, ' issue-specializes-issue, 

'  issue-replaces-issue, 

'  issue-questions-issue, '  issue-suggested-by-issue, 

'  issue-suggested-by-position, 

'  issue-suggested-by-argument, 'position-responds-to-issue, 

'  argument-supports-position, ' argument-ob jects-to-position, 

' argument-depends-on-assun^tion, 

' assunption-qualifies-argument, 'decision-resolves-issue, 

' decision-selects-position, 

'  decision-generalizes-decision, ' decision-specializes-decision, 

'  decision-depends-on-decision, 

' decision-irqjlies-constraint, ' decision-leads-to-constraint, 

'  decision-generates-constraint, 

'  constraint-creates-design-object, ' constraint-removes-design-ob ject, 
'  constraint-modifies-design-object, 

' design-ob ject-depends-on-constraint } ) , 
title-string) ; 


let  (dw:  diagram-window  =  make-object (' diagram-window) , 

surf:  diagram-surface  =■  make-object (' diagram-surface) 
) 

add-colored-icons-to-window (dw) 


function  graph-remap-model-for-module  (kbm:  kb-module)  * 

let (remap-nodes :  set (remap-node)  -  {x|(x)  x  in  owned-objects (kbm) 

&  remap-node (x) } ) 

let (kbm-remap-issues :  set (remap-issue)  -  filter (remap-issue, remap-nodes) ) 
let (kbm-remap-decisions :  set (remap-decision)  =  filter (remap-decision, 

remap-nodes) ) 

let (kbm-remap-constraints :  set (remap-constraint)  =  filter (remap-constraint, 
remap-nodes) ) 

let (kbm-remap-design-objects:  set (remap-design-object)  = 
filter (remap-design-object, remap-nodes) ) 

let (kbm-remap-assun?)tions :  set (remap-assunption)  =  filter (remap-assunption, 

remap-nodes) ) 

let (kbm-remap-positions :  set (remap-position)  = 
filter (remap-position, remap-nodes) ) 
let (kbm-remap-arg\unents :  set (remap-argument)  = 
filter (remap-argument, remap-nodes) ) 
let (kbm-remap-requirements ;  set (remap- requirement)  = 
filter (remap-requirement, remap-nodes) ) 


graph-remap-model  (remap-nodes, 

format (false,  "REMAP  Model  for  KB-module:  ~a", 
name (kbm) ) ) 


function  contains-remap-nodes?  (button:  symbol,  kbm:  object, 
pos:  point,  w:  window'  : boolean  = 
ex(x) (x  in  owned-objects (kbm)  &  remap-node (x) ) 


function  invoke-graph-remap-model-for-module  (button:  symbol,  thing:  object, 
pos:  point,  w:  window)  =  graph-remap-model-for-module (thing) 
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